KML as a mapping language is clearly gaining momentum around the world. It is used as the means for map display in both web sites like Google Maps and Virtual Earth, but also in a range of more conventional mapping and GIS products. Web Map Servers (OGC) can now provide maps in KML as well as more traditional image formats like GIF or JPG. This posting, looks at the use of KML in a slightly different context, namely that of creating observations.

We motivate the discussion by considering the use of probe cars to digitize highway and road infrastructure. An increasing number of vehicles are equipped today with navigation devices – so called “GPS” units that provide on board map displays and guide you from one destination to another. Of course such units can also be used to capture the vehicles position for an external data collector and in doing so capture aspects of the geometry of the road, or the current speed of the traffic where the vehicle is located. This raises the obvious question. What is the relationship between the track recorded by the GPS unit in the vehicle, and the road features that populate the database on which the navigation unit’s map display is based?

We assert that the GPS track, however recorded, is an observation and that such observations can be used to generate or update the feature model of the road network. Furthermore we propose that KML can be used as a means to capture such observations.

Observations (see GML specification) model the “act of observing or measuring”. As a result an observation has specific properties like the time of the observing, possibly the location of the observer (this is the result in this case), the result of the observing (e.g. vehicle speed, vehicle location), the target or subject of the observing, and the instrument or procedure that is employed. Now we should be clear that no such construct currently exists in KML. There is no supported means to distinguish an observation from the styling of a feature (e.g. the road) for presentation. Nonetheless, the idea of using KML to capture this information is attractive, since we can anticipate the use of KML for map display in future navigation devices. How to do it?

Assuming that we do not make any extensions to KML (more about that in a future blog), how should we represent an observation. One approach is to use KML Extended Data and add some elements from GML. Specifically we add elements in the Extended Data from GML Observation, namely Observation, target, and using. Note that an application schema extending observation could have been created if additional user properties were desired such as observer name, description etc. To simplify matters we will stick to the use of core elements of GML. Note that we do not include in the observation the gml:validTime or gml:location as these are captured in this case by the KML encoding of the track as a PlaceMark. We also do not include gml:resultOf in this specific case as only location information is being acquired. We could include a gml:resultOf if we were to include other parameters in the observation such as vehicle direction and speed.

Detection of the gml:Observation in the PlaceMark designates this PlaceMark as an Observation.

So how do we get from Observations to “authorized” features.

A feature is a model of some aspect of the world. Features are named typed entities with properties specific to their type (e.g. a Road has a number of lanes, driving directions for the lanes, lane width, surface type and so forth). Features arise from some form of community agreement. This may be formal or even legal (e.g. the boundary of a land parcel), or it may be quite informal. For roads it is both formal and legal, however this formal and legal agreement is a function of jurisdiction and varies from one part of the world to another.

We can thus create a particular road model (list of properties (fields) and their types) that represents the community understanding of road for a particular jurisdiction. This road model can be expressed in a GML application schema. The tracks encoded in KML can then be used quite directly to construct GML observations about the road network which are then forwarded back to the road network custodian for integration into the road network model. Accumulation and analysis of multiple such tracks then leads to modifications to the road network which may then be propagated by OGC WFS transactions to the network of road databases and to the in vehicle navigation devices themselves. In the navigation device the updated data can be styled into KML for presentation to the driver, with styling appropriate to the driver’s locale.

Note that this process of presentation => content (capture observation content) => presentation (style updated content for presentation) is a basic part of the separation of presentation and content and exploits the power of both KML and GML.

Ron Lake, Chairman and CEO, Galdos Systems, Inc.