September 14, 2005

What is KML?

It is clear that KML is a success in the sense of attracting the eyeballs of the world to Google Earth. As I have said here, and elsewhere, Google Earth is an impressive achievement. It redefines how consumers think about location information. Google Earth provides a complete application with a supporting environment incorporating both maps and images on a global basis. It is this aspect that is more impressive than any other!  In fact, the genius of Google Earth is that it is a communication mechanism between people.

In terms of KML - Google's language for referencing places on the earth "LookAt" at this place - and to symboloize that "PlaceMark".  "Here I went on holidays" - "Look at me on the beach".

This is clear. It is equally clear that maps on Google Earth are not yet available in KML nor is it likely that the data underlying these maps is based on KML.  What then are the functions of KML.

It seems to perform several functions, including:

  • Encoding of geographic features.
  • Expressing styling rules for the graphic (map) visualization of geographic features.
  • Expressing the actual graphical appearance of the visualized geographci features.

Encoding Geographic Features

KML provides a basic "feature like" construct called a PlaceMark.  A PlaceMark has a number of "properties" including:
  • <LookAt> - where to Look at on the earth.
  • <Point> - presumably the Point on the earth where the Place is located?
  • <visibility> - the visibility of the symbol for the PlaceMark on a Google Earth map.  Enables the PlaceMark to be visible or invisible.
  • styleURl - refers to a style that may exist remotely.   The Google documentation (http://www.keyhole.com/kml/kml_doc.html#Placemark) does not make it clear where the <Style> element appears in <PlaceMark> but it the <Style> definition says it can be used within a <PlaceMark>.

One could easily create a GML representation for <PlaceMark>, treating it as a GML feature.  So far so good.  What about using KML to represent other geographic features?  It seems unsatisfactory to say that all geographic features need to be represerted using <PlaceMark>.  How would we encode say a building with a polygonal extent, a number of floors, a height, a position, a type (e.g. Church, Police Station etc), and the date when the building was erected.  This is less clear, based on the existing documentation. One could use the <Schema> construct something as follows:

<Schema>
  <name>Road</name>
  <Parent>PlaceMark</Parent>
  <SimpleField>
    <name>numLanes</name>
    <type>uint</type>
  </SimpleField>
  <SimpleField>
    <name>surfaceType</name>
    <type>wstring</type>
  </SimpleField>
</Schema>

It is not clear from the documentation just how one uses the created <Road> element, nor how one might express restrictions on the geometry properties of the object, nor how to express relationships.  At least as far as the provided documentation goes, KML seems a pretty limited basis for representing geographic objects.  KML does not appear to clearly differentiate between an object and the visual appearance of that object in Google Earth.

Styling rules for the graphic (map) visualization

KML is not only a language for representing geographic objects, but also one for the expression of styling rules for the graphical representation of those objects.  This is handled in KML using the <Style> element. The <Style> element provides limited abilities to specify the visual properties of text, point, line and polygon geometric elements. A Polygon can be filled with a single solid colour for example, and it can it have a boundary or not.  There does not appear to be a way to determine the colour or weight of the boundary curves.  There appears to be no means to fill a polygon with hash or other patterns nor to fill it with symbols.

There does not appear to be any ability to express styling rules that depend on the characteristics of a geographic feature - for example a <Road> with three lanes should be a thick red line, while a <Road> with two lanes should be a thin yellow line.

Since KML does not clearly distinguish feature representation from graphic visualization, it is hard to say that KML really provides a Style Language such as in GML default style, or OGC SLD (Styled Layer Descriptor).

Graphical Encoding

KML is focused on visualization within the Google Earth application.  As noted above, the <Style> elements above can be interpreted as style rules (weakly) or as simply specifying the graphical output in Google Earth.  In this sense, KML is similar to SVG, but with 1) a binding to Google Earth and 2) description of geometries in WGS84.

 

Posted by RLake at 21:07:47 | Permanent Link | Comments (4) |
Comments
1 - hi ron

excellent posts.

the last schema example is not showing up.

brian (Comment this)

Written by: Brian Flood at 2005/09/16 - 12:45:18
2 - Hi,

Can anyone give me some URLs where I can find GML files for XSLT transformation testing?

I have made a converter/translator for GML(polygons) to KML, GPX to KML, KML to GPX etc.
I would like to expand the GML2KML xslt sheet to cover more GML features.

http://members.home.nl/cybarber/geomatters/KmlGpxGmlTransform.hta
(Windows/IE HTML Application)


Transformation Sheet: http://members.home.nl/cybarber/geomatters/GML2KML.xslt

Cybarber
 (Comment this)

Written by: William A Slabbekoorn at 2005/10/02 - 11:28:41
3 - Ron,
you should take a look at http://kml.tjworld.net/#reference
TJ has put together a comprehensive KML reference that some say is better than that supplied by Google. (Comment this)

Written by: grasshoppermind at 2005/11/07 - 12:06:21
4 - Remember old HTML? It mixed data with the means of rendering that data: style. In the real world, different people want a different view on the same data. Because of this, it is now widely accepted dogma that style should be *applied* to data, not mixed in with it. XHTML and CSS were what followed. XML and XSL follow the same principle of separating the two.

Has KML not kicked off on a worrying track, therefore, by merging feature data with styling rules?

Perhaps it was done with a view to keeping KML simple? Yet due to the success of Google Earth, there is now much excitement about what features will be introduced next. New features must lead to greater complexity. And with greater complexity, is the lack of separation between data and style not going to result in a very messy specification? (Comment this)

Written by: David Martin at 2006/04/12 - 13:02:51
Write a comment