20 Apr 2007 - Transporting GML in KML

In the past year, Google's KML has emerged as the dominant geographic visualization and annotation language on the planet. Millions of KML files are being used to describe places all over the globe from the troubles in Darfur, to everyman's last visit to Paris. KML is about story telling with a geographic flavour. In many ways it is like SVG, except that the drawing canvas rather than being your screen, is the Google Earth image backdrop - the virtual globe.

What KML does not try to do is to express geographic content. This is to say it does not provide a means of representing geographic entities (aka features) in terms of their properties. The schema construct introduced in an earlier version of KML has now been deprecated, and replaced by the more general and more agnostic Metadata tag. This is a significant change as it defines a clear boundary between what KML is, and what it is not. Nonetheless, KML does provide the ability to transport this information, and KML processors by Google and others are expected to leave the content of the Metadata tag alone (not change it) unless they are explicitly designed to do so.

This makes for an ideal partnership between GML and KML. GML is not about geographic visualization, but about geographic content description. Where KML is "place centric", GML is "feature centric". Where KML deals with the presentation of geographic things, GML seeks only to describe them in formal terms, quite apart from their presentation. Of course this means that it is natural to talk about styling GML data, meaning to apply interpretation rules, in order to generate a KML visualization. However, much more is true and that is the subject of this blog.

The <Metadata> tag in KML can simply carry GML. This means I can write something like:

				<PlaceMark>

				    <Metadata>

				        ... put GML data here ...

				    </Metadata>

				    <Point> .. </POint

				</PlaceMark> 

The GML can then hold properties of the objects within or connected to the <PlaceMark> thus providing a more formal description that is required for database update, analysis and other types of data processing.

Since Google already scans the web for KML files, any such KML containing GML objects will be indexed by the Google robot and be retrievable with any web browser. This will enable some quite sophisticated GIS visualization and analysis as we shall see in the weeks to come.

The neat part of this is that it can be done very simply. The GML can start off as nothing more than a way of capturing simple properties of an object. For example, suppose we have an object like a discontinued oil well. The location of the well is of course very important, but even more important will be information such as 1) discontinuation date 2) the owner's name 3) extraction technique last used 4) volume flow when capped 5) estimated remaining reserves. The GML for such a list of properties will be will be very easily constructed and might look as follows:

<abc:CappedWell gml:id="c454">

    <gml:description>Cape croker</gml:description>

    <abc:ended>1989-04-02T12:21-05:00</abc:ended>

    <abc:owner>PetroCan</abc:owner>

    <abc:extraction>Secondary - beam pump</abc:extraction>

    <abc:Volume gml:uom = "... Bbls/d">28.2</abc:Volume>

    <abc:reserves gml:uom="..Bbls">25000</reserves

</abc:CappedWell>

Using this approach we can easily move data to and from spatial databases, as well as produce KML visualizations that depend on the contained GML - e.g show the wells with > 50000 Bbls of oil in RED.

This is of course only the beginning. There is much more to come! Stay tuned.

Comments

No comments yet.