Monday, February 2, 2009 at 4:38 PM
As you may have heard, a new version of Google Earth was released today. As has been the case with many Google Earth releases, this new version required expansions to KML, Google Earth's most important supported file format. After all, developers want access to all the interesting new features that have been added to Google Earth's UI.
Only one problem: Google no longer controls KML. We submitted it to the Open Geospatial Consortium (OGC) last year, where it is now maintained as an official OGC standard. The solution: extension namespaces!
You see, the OGC specification for KML includes explicit hooks for vendors to create their own extensions to the language, using XML namespaces and XSD. This allows the creation of new elements that extend or add to existing ones. For example, Google's extension namespace is now declared at the top of KML files that are emitted by the new Google Earth 5.0, with an XML namespace declaration:
xmlns:gx="http://www.google.com/kml/ext/2.2"
This tells parsers of that file to expect elements from that namespace in the file, prefixed by gx: (to distinguish them from the standard KML elements). So for example, the new touring feature in Google Earth can be expressed in KML with a <gx:Tour> element, in any KML file that includes the xmlns declaration above. Standards-compliant applications that don't understand the new namespace will simply ignore the new elements.
This allows us to comply with the standard specification for KML, without unduly restricting us from innovating and experimenting. Other vendors are also placed on similar grounds with respect to KML extensions, enabling a marketplace of innovation surrounding a core standard language.
But wait, there's more!
As previously announced on this blog, Google released and maintains a reference implementation for KML reading/writing: libkml. So it brings me great pleasure to point out that on the same day that the Google Earth team releases support for new KML extensions, we're also releasing libkml v0.9, which fully supports all of the new extension elements as well. This new version of libkml can be used to read and/or write all of the new KML elements, including those used for time slider control, the new altitudeMode for ocean data, and of course, the largest new feature in KML... Touring, which enables controlled camera and object animation.
So by all means, check out the new Google Earth, and check out the new libkml. Developers interested in the fine details of the new extension elements are advised to check out our section on that topic in the KML reference.
6 comments:
hmm, think that using the gx prefix wasn't a good idea.
gx is already commonly used as an abreviation of GeneXus, www.genexus.com
Artech (producer of GX) and the genexus community prefix genexus products, services, tools, etc with gx. GeneXus itself is often called GX.
Hi Armin. I appreciate your concern.
I suspect it's not uncommon to have such collisions when you're talking about XML prefixes like gx, since an XML author is inclined to choose small abbreviations when they pick a prefix. There are, unfortunately, many companies and groups in the world that would match any two-letter code one could choose (there just aren't that many two-letter codes, compared to the number of groups in the world). But even more importantly, it's not a required naming collision...
Declaring the "gx:" prefix the way my post shows is not much different than declaring a "gx" variable in a program. You can actually pick any name you want instead of "gx", as long as you use the same name everywhere in that particular KML file. Google had to choose a useful mnemonic of some sort for our examples, though, and "gx = Google eXtension" in our head, so we hoped it would be a simple and memorable way to depict the extension element namespace.
I'm optimistic that it won't cause unnecessary confusion, since it's only visible to KML programmers.
So, would you recommend this private-namespace technique for those of us (outside of Google) trying to push an enhancement of KML? For example, refer to my feature request:
http://code.google.com/p/kml-samples/issues/detail?id=213&colspec=ID%20Type%20Summary%20Product%20Status%20Priority%20Owner%20Stars
What would you recommend here?
ObPlug: We just released our VNS 3.03 with support for generating GE 5's Guided Tours in our Scene Express add-on.
http://3dnature.com/vns3fotw-ge5.html
http://3dnature.com/kml.html
BUT, without proper control of Camera FOV, we can't correctly match the view the user originally may have specified in our (more flexible) camera model.
Michael, OK, i understand, thank you!
Would the obskml: extension listed at http://tinyurl.com/a9q8wf be a valid use of the extension for providing a common observation based schema ?
Xenon-
You're not the only person to suggest enabling programmatic FOV control in Earth via KML. However, at this time it's just not an aspect of the view control that we support.
Google Earth already ignores any elements it doesn't understand (as should any compliant KML parser), so in general there would be no "harmful" effect from elements like you suggest. However, in order to do as you suggest "properly" and still conform to the KML specification, you'll need to create and publish an extension XSD that describes the new elements you want to use. In order to follow this route, you'll need to put any/all new elements into your own namespace (i.e. it's not possible to use an extension XSD to specify that existing elements can be used in new ways... you'd have to duplicate "ext:ViewVolume" in your own namespace, for example).
Last but not least, the OGC maintains the complete guide to extending KML:
http://portal.opengeospatial.org/files/?artifact_id=30203
A more light-weight approach to adding custom data to a Placemark that might serve you well is ExtendedData:
http://code.google.com/apis/kml/documentation/kmlreference.html#extendeddata
Post a Comment