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:
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).
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.