KML @ OGC

17 Apr 2007

Well, the Open Geospatial Consortium (OGC) Technical Committee (TC) meeting is once again proving to be the Most Boring Meeting in the Known Universe. The best came on the first day, with the plenary session talks, and the Mass Market meeting, with the entrance of Google Earth’s KML into the OGC.

I attempted to capture Michael Jones’ (CTO Google) explanation verbatim, but am not a professional stenographer. So take the below as a loose quotation:

“Why go this far [submitting KML to OGC]? So we could go further. A lot of people are using Google Earth. It is thrilling to us. It [KML] is a pretty standard format, even though it is vendor controlled. It seemed to us like the Microsoft Word .doc format. Will become more and more a de facto standard. If we could put it into a standards body, they could shape it. It would be a better outcome. We wanted [KML to be] HTML for the geospatial web. Our fledgling efforts have got us this far. We don’t want to bail on this [continuing development of KML], but will support a standards effort in the future.”

“We thought we could codify the current state [of KML]. And then over the next while work together to build a new KML that is a lot like the current KML, but would be built according to the standards body process. Between here and there, could be mid-points, stops along the way, but that is the path. This [submitting KML 2.1 to the OGC] is not the whole activity, it is the first step along the way.”

The quotation captures Jones’ excitement about the potential of KML as an interchange format, a way of sharing and linking geospatial data. The process of bringing KML into the OGC will be:

• The OGC will develop a “position paper” explaining how KML relates to the OGC standards baseline.
• KML 2.1 will be re-published as an official OGC “best practices document”.
• The OGC Mass Market working group will begin working on KML 3.0.
• In the meantime, Google may add changes to the KML 2.X stream, and the OGC Mass Market group will decide whether they are worthy of propagation into KML 3.0.

The whole process is anticipated to take less than a year.

The pivot on which all this turns is the idea that KML is similar to HTML, as a content encoding that will be consumed by multiple clients (“spatial browsing software”), not just Google Earth. The market already seems to be well on the way to that end state – there are lots of KML consumers (ArcGIS, FME, World Wind) and producers (ArcServer, PostGIS, Mapguide). Given such an emerging market, KML will be healthier and grow even faster under third-party control (OGC) than under corporate control (Google).

There were some questions after.

The OGC has spent a good deal of time and effort carefully separating concerns in their standards: there are content encoding standards (GML), and styling standards (SLD), and filtering standards (Filter), and behavior standards (WMS/WFS), and they have been carefully kept separate. KML merrily stuffs all those concerns into one pot. Asked about this disconnect, Google reps were unapologetic, saying that the very combination of concerns allows for the simple user experience which makes Google Earth (and by extension KML) so compelling. I agree. Bundling the concerns together makes deployment simple, and does not preclude the over-riding of styling, etc, by the client software.

I had to ask the question that was on my mind: if KML 2.1 was going to be an OGC “best practices” document, but Google was going to continue to add features to the 2.X series of KML, how would the KML 3.0 work re-converge? Basically, was the OGC just going to end up rubber-stamping whatever features Google felt like tossing into the 2.X series in the period prior to the 3.0 release.

Michael Jones answered that vendor extensions are a time honored part of the standards development process, that the innovation around standards is what drives them forward. Citing his time in the OpenGL process, Jones noted that companies would add proprietary extensions to their hardware that were not in the standard, but that the worthy extensions would end up pulled into the standard at the next revision. I replied that there was only one vendor in this case, Google, which made for an unhealthy balance of power. Jones said he had approached Microsoft and ESRI to join in the standardization process of KML, and will continue to invite them to the table. In the end, an OGC process with Google and invitations to the others is better than no process at all. I find it hard to disagree with that.

A similar process has driven development of HTML – it is not always pretty, and sometime people yell at each other, but in the end the standard moves forward and everyone has a known baseline to work against. With more and more applications using and creating KML, it is important for companies to have a solid baseline they can trust.