GeoWorld-May 2007
Building the GeoWeb
By Ron Lake, president, Galdos Systems Inc.; e-mail: rlake
galdosinc
com .
When I first encountered KML, I thought of it as a competitor to GML or, at best, an alternative. On further reflection, I thought that KML overlapped several other Open Geospatial Consortium (OGC) specifications, including Styled Layer Descriptor (SLD), context (map-view specification) and XIMA (annotation).
On still further reflection, I realized that there’s only minimal overlap, and KML and GML serve different, yet complementary objectives. That’s quite a transition. How did I come to this realization? And what’s KML anyway?
Definitions and Objectives
KML is about geographic visualization—not content representation and styling. KML is focused on the visual description of places on "Earth’s surface," meaning things on, below and above the surface. It’s "place centric" and not "feature centric." It doesn’t try to describe a real-world object and tell where it’s located. Rather, it says "here’s a point or line on Earth, and this is what’s there."
In many ways, KML can be compared to SVG. But, in SVG, the canvas is the 2-D surface of a computer screen; in KML, it’s Earth’s surface. This makes KML a type of annotation language focused specifically on the Google Earth image backdrop.
In developing the XIMA language at OGC, the critical realization was that annotations were associations among geometric regions on a map or image and the annotation text, imagery or video. This seems exactly like KML’s objective (think balloons with HTML inside).
Part of the confusion respecting KML’s role arises from widely held misunderstandings about data "conversion." In my view, it makes sense to talk about data conversion only for entities or files with the same or similar semantic content. It doesn’t make sense to talk about "converting" Shape to SVG, nor Shape to KML. It does make sense, however, to have KML carry some of the content of a Shapefile using the <metadata> or similar tags.
Logical Partners
GML is first and foremost about geographic-content representation. It provides a base set of geographic objects and a simple extension mechanism by which users can create application-specific vocabularies.
Unlike KML, GML is feature centric. An object is defined in a GML application schema that may or may not have geometry-valued properties specifying its location or shape. Furthermore, using the <metadata> construct, some of the GML content can be carried as an aspect of place. I anticipate that complete GML objects could be associated with KML places in the near future.
Google recently began to spatially index the Web, initially based on using KML files. Note that such files can be used to describe the footprint of OGC Web services such as WMS and WFS as well as the footprint of GML data collections, although the latter will mostly be found behind WFS or WCS (i.e., GMLJP2). So a KML file might readily identify that there’s a WFS that serves GML data with some type of extent (shown graphically on Google Earth).
KML and GML also are logical partners in the same way as SVG and GML. GML can be "styled" (not converted) into KML to visualize GML-encoded geographic content on the Google Earth image backdrop. However, although KML talks about styles, it isn’t a styling language in the manner of OGC’s SLD. The latter is concerned with the rules that define the styling of geographic content into some type of visualization.
It thus makes sense to talk about applying SLD styling rules to GML to generate a KML visualization. A further visualization can be constructed using the WMS functionality of Google Earth (in this case, the GML can be styled to SVG and then handled as an image overlay).
So having established GML (content representation) and KML (geographic visualization and annotation) as partners, how can these specifications best be harmonized? Clearly the first place to start is geometry.
KML already uses the geometry of GML 2.1.2, so migrating to the coordinate model and nomenclature of GML 3.x can be easily done. Given KML’s mission, it may not be necessary to support all of the GML geometry constructs, but those dealing with 3-D ought to be considered as well as those such as Geodesics and Beziers.
Do we need to take harmonization further? Should KML need to formally adopt the GML object/property/value structure? Time and more discussion in the marketplace will likely dictate the answers. Stay tuned.
Read the article on their website: Geoplace.com.