In the meantime MS seems to be headed done the track of merging WPF/XML and 3D terrain streaming that would make kml2.2 more or less anachronistic. OGC needs to push ahead toward KML3.0 with some kind of client event capability.

I’m not partial to any GIS flavor over another; whatever is best for the problem at hand is the best one to use. However, Google has found it’s way onto my desktop – into my web browser – and onto my blackberry and I didn’t pay a dime.
It just works.

Of course, the cynic in me is just waiting for Google to start charging for new API keys.

Google/Keyhole could have worked with OGC to make GML better for their needs, but ended up created their own format.

Bullshit. OGC would never have approved of changing GML to match the needs that KML meets. The use of feature-based styling is completely antithetical to everything that OGC has pursued for the past several years, and core to KML.

There was no way for OGC to evolve something like KML. There *is* nothing else like KML in the Geospatial world: there is no language which combines geometry + attributes and style/visualization rules in one format, and that’s the key thing that KML is all about.

The ‘feature’ part (which maps to GML) is close enough to GML that it is essentially as easy to support as another format of GML. (I’ve not yet seen any evidence that anyone actually supports *all* GML, only their particular flavor.) The style bits that make KML difficult to support don’t *exist* anywhere else within OGC, so it’s not ‘another format’, it’s ‘a visualization format’: no others exist in the GeoSpatial space. Everyone else (even ESRI!) seperates these aspects out.

You can argue all day over whether feature-based styling and the combination of content and styling makes sense, but you can’t claim that the right move was to try to force something like KML through OGC channels: they’d be fighting for another 10 years if they hadn’t gained more usage than all of WMS/WFS/SLD together on the public web *first*, before pushing through OGC.

Our meaning, which many people understand, is that the broad acceptance of KML due to Earth & Maps provides the opportunity for all Earth browsers to rally around a shared markup while competing on features and data. We likened this to the Mosaic/Netscape/IE and HTML situation where different products could share the [mostly] same markup language. Our idea was to do better than that by having the standards process get started early and by subjugating our own commercial preferences in exchange for making a standard that other companies and even countries could embrace.

It has worked well so far. ESRI, Microsoft, NASA’s World Wind, and Matt Giger’s EarthBrowser all visualize KML, Adobe and others have tools to edit it, and many companies have tools to generate it. Microsoft even has reason to claim that they can visualize it better than Google Maps. This thrills me in that the debate is not a divisive battle between 20 alternative formats (a la Word, WordPerfect, …) nor is it a single dominant format as closely held IP (Word again.) Instead, we have the Google approach of being open and welcoming at the moment of our strength, a move designed to empower broader use of GIS and mapping by billions of Web users and the million or so traditional GIS users.

While some who’ve posted here may disagree, I think this bold step has been the right thing to do. The world we’re working to create is one almost exactly modeled on the role of HTML as in industry organizing principle, but in this case, for geospatial visualization.