2006 (old posts, page 13)

Atom feed RSS feed

Java Worldwind?

There's going to be a Java Worldwind as well as .NET Worldwinds? Does this multiplication seem like a waste of resources to anyone else? What's wrong with .NET? Does this imply that Mono is still a toy? Why wasn't it written once in C++ or Java? That's a lot of questions, but I'm seriously baffled.

Comments

Re: Java Worldwind?

Author: Erik

The answer to all your questions is probably just NASA politics. From a World Wind forums post a while ago, the NASA developer (there's just one) said that the original work was done in C# and Managed DirectX because that meant the project could be done in the very limited time and budget allowed while still reaching as many people as possible. "Going the C# route was the difference between finishing the project, and not finishing the project." http://forum.worldwindcentral.com/showthread.php?t=7

Re: Java Worldwind?

Author: nigel

The problem with a mono World Wind is that the reliance on DirectX keeps it from being cross platform. A Mono/OpenGL World Wind would be cross platform but requires a major rewrite...almost as much as a Java World Wind and Java is more widely accepted and more importantly it makes World Wind easier to integrate with existing java projects. Is it a duplication of effort? Yep. Is a Java version going to be really useful? Yep. Will I have to rewrite all my plugins? Yep, but it makes it easier to integrate with other Java projects around my lab. Being java it reduces the entry barriers. For example, I know that one of the mission planning systems for the Mars Reconniassance Observer is written in java and its visualization isn't as nice as the World Wind one. But integration with a C# WW would have been annoying so there wasn't much interest. A java WW would have been much easier to integrate and may have gained traction. A mono one? Not so much. There's nothing wrong with .NET or mono but there are some advantages of java that outweighs the duplication effort IMHO. How that pans out in real life...well, we'll see. Regards, Nigel ObDis: Not speaking for my employer

Re: Java Worldwind?

Author: Adam Hill

The short answer is yes. But the longer and more ironic reason for the Java version is resources. :) Just because a project is done wholly or in part by NASA does not mean they have infinite resources to do what ever they want. So if one year a group is willing to fund Chris Maxwell and company to do X, does not mean that in the next year funding will continue. So in this case someone else inside of NASA wants a World WWind style viewer for integration for Java (Eclipse) apps and is willing to pay for it. Just like in any other large corporation, development is driven by need. (Or a managers selling abilities) With regards to the Mono question, as someone that has compiled WW in Mono, all of WW compiles and if you Mock the Direct3D code you can actually get a Window up with a large black rectangle in the center on Ubuntu, so I would say Mono is pretty mature. But what is missing once you overcome that hurdle is a 3D abstraction layer for using D3D or OGL in the application, depending on your choice. There are many OpenSource 3D engines that do this quite well and a few already running with Mono wrappers. Anselm Hook has thrown out the 'couple of months' number for a conversion. And Tao, the OGL wrapper for .NET has come a long way in the years since WW has been developed so it might be much, much easier to do this now. In the past Summer of Code competition we actually had two submissions for making WW use OGL, but got prioritized down. Maybe we will accept them next year. So if the need becomes strong and someone steps up, it is technically feasable. Viva la Open Soruce!

Re: Java Worldwind?

Author: Chris Maxwell

Simple answer: Funding.

C#/Java/ X Platform

Author: What_nick

DirectX managed mode actually gets slightly better performance than Java-JOGL. Anyway We currently have Tao-the OpenGL Mono wrapper in the Worldwind source tree.We use the Tao GLUTessalator for rendering polygons. Switching all the rendering code to OpenGL is a bit of work as anyone can imagine. The Java Worldwind project is in effect switching the renderer to OpenGL. Hopefully it will not be hard to port that code to Tao once someone has the initiative/funding/itch to do so. Anyone from Novell willing to do some funding ?

Another Milestone

I was just solicited to write some blog-ola about a vaguely geo-related product that I'll never use. Weird. I'd never do that in a million years.

Coaster

Speaking of commercial products: Fall -- and Saison -- couldn't arrive soon enough beer-wise. New Belgium's summer seasonal beer, Skinny Dip, was as gustatorially disappointing as it was profitable. Carefully and precisely made, it had no aftertaste, no middle taste ... no flavor at all, to be honest. This was a beer for the masses, for people who found Fat Tire to be far too heavy and rich. Even the tasteless bots who drink Smirnov coolers found Skinny Dip to be refreshingly and perfectly unchallenging. I should have seen this coming a couple years ago when I got the awesome (I'm serious!) behind-the-curtains tour of the N.B. cellaring operation, and learned that the favorite in-house brew of the cellaring team was their lightest beer at the time: Loft. Skinny Dip must have started as an after-work bet:

"Dude -- I bet we can make a beer more crisp than Loft."

"Oh yeah? I bet we can make a beer crispier than Bud Lite!"

Just because you can doesn't mean you should. Unless Skinny Dip's profits could subsidize lower prices on La Folie, or pay for year-round production of Lips of Faith.

Comments

Re: Another Milestone

Author: GeoMullah

Here-here! What was N.B. thinking?

Re: Another Milestone

Author: Jeremy

Nothin beats New Belgium's Trippel Belgian Style Ale. 7.8% and lots of hops!

Trippel

Author: Sean

Trippel is one of my five favorite beers.

Re: Another Milestone

Author: Wyatt

"...for people who found Fat Tire to be far too heavy and rich." This must be some of that "irony" stuff, since FT is light and smooth and ever so tasty, one of the only beers I like beyond the first few sips. /useless comment

Denver Plone Meetup

Trey Beck is organizing a first local Plone meetup:

Friday October 13 at 6:00 pm at the Alliance Building, 1536 Wynkoop St (next door to the Tattered Cover in LODO). We'll have internet access and a projector, I think. Spread the word!

I'm looking forward to hearing what people are up to, and to showing off Pleiades and PrimaGIS.

Framing GeoDRM

Last "International Talk Like a Pirate Day" I wrote and tore up several lackluster posts about GeoDRM. None of them had the "Arr" I was searching for. I'd received emails offline from an OGC person who was trying to convince me that it's too early to criticize GeoDRM; that it is just a reference model, reference models can't be implemented, that it has nothing to do with implementations. This is a person I know, respect, and like, and I regret to say that I wasn't convinced. Now is the critical framing stage of the GeoDRM debate. I'm opposed to heavy-handed technological enforcement of copyright, and I'm not going to sit on my hands while the debate is framed in favor of enforcement.

Browsing Ancient Lycia and Pisidia

Pleiades reached its first data milestone today. We've loaded up all point features from the Barrington Atlas Map 65: Lycia-Pisidia. Map 65 (dead center of the locator map) was compiled by C. Foss and S. Mitchell, and edited by R. Talbert (see credits). The Pleiades portal provides KML and GeoRSS views of all features and folderish collections of features. The latter are used within the site in conjunction with several OpenLayers-based maps.

Choma in Google Earth

Lycia was an early Greek colony in Asia Minor and, later, a Roman province. Pisidia is mountainous country, and its peoples mounted a long insurgency against Greeks and Romans. Archaeologists are active in this region: at Sagalassos and Choma (site currently down) in particular. The Choma network link from Pleiades is well worth a visit. The dig itself is found 1.5 kilometers NE of the 1:500,000 scale Pleiades placemark. Google has recent high-resolution imagery for the region, and you can easily see the site and excavation. The next development milestones for Pleiades focus on creating the scholarly workflow that will improve the locations, historical names, and bibliographic references of these features. Dare we call it "Scholarship 2.0"?

All contemporary features can be viewed using the Imperial Roman period network link.

Initial startup funding for Pleiades is generously provided by the U.S. National Endowment for the Humanities with a two-year grant (2006-2008) through its Preservation and Access Research and Development program. Hosting for Pleiades during this period is provided by the Stoa Consortium and the Collaboratory for Research in Computing for Humanities at the University of Kentucky.

MapWho?

It's interesting that MapServer doesn't make the cut on the OSGeo web mapping matrix (rev 8323).

Comments

Re: MapWho?

Author: Gary

I think the point of the list is web-mapping clients, not the underlying server software.

Re: MapWho?

Author: Jason Birch

Sean, The revision that you cite clearly states "It may or may not depend on a particular server technology (like MapServer or MapGuide). This page focuses primarily on Open Source browser-based clients (not the servers)." This point aside, I think it's unfair to point to this as the OSGeo web mapping matrix, as it's certainly not an official document. It's linked from the main page under "Proposals and Other Working Pages". If there's something missing, please use the power of the wiki to add it. Jason

ESRI and IronPython

Seems like a good fit to me. ESRI doesn't have any investment in the Python language or community. I think the company simply chose the language with the least syntactic distance from Avenue. I've been following news of IronPython since Hugunin switched to it from Jython. This was prior to his hire by Microsoft. I have not yet downloaded it to confirm directly, but I expect that it would be -- via the CLR and COM interop -- a better bridge to all the COM in ArcGIS than is C Python.

Federal Task Force Recommends Standards

Good sense prevails! A task force reviewing federal GIS recommends that the best strategy for consolidation is standards not centralized services. Like the web itself. Via All Points Blog.

Comments

Re: Federal Task Force Recommends Standards

Author: Tom Kralidis

What a concept, eh! One can see this in two ways: 1./ Yes, decentralized and web services oriented, which definitely addresses distributed activities 2./ totally centralized, which also makes sense to an organization as an enterprise. The key factor is how an organization is setup IT-wise; do they have a centralized IT / publishing function? Or are these activites disparate? In either case, Web Services provide the obvious advantage of better chance at up to date / authoritative data, no matter what level they are deployed at within / between organizations.

Re: Federal Task Force Recommends Standards

Author: Dave Smith

Standards opens the door for both approaches to be taken. Without standards, a decentralized approach is the wild west. The hope is that the OMB beancounters recognize that governance is the most critical part to develop in the Geo Line of Business - all else turns into a cat-herding exercise.

Python 2.5, me Maties!

What's in the brand spanking new Python 2.5 for geospatial folks? New standard libs:

  • ctypes: call functions exposed from DLLs and shared libraries. This gives us an even more direct way to leverage geospatial libraries than SWIG does.
  • ElementTree: the natural way to program with XML now ships with Python.
  • cProfile: I've been using the slow profile.py quite a bit in developing the Python cartographic library. This more efficient module comes out of Google's Summer of Code.

Completed PEPs:

  • 341: Consistent exception handling -- finally.
  • 343: Context management not unlike Ruby blocks.

Python 2.5 is also significantly faster than 2.4, string programming in particular.