Tuesday, April 17, 2007

KML @ OGC

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.

4 comments:

rlake said...

I think this note is a little misleading. If you look at KML you will realize that it is a visualization language and NOT a content or styling language, and does not really have these things rolled together as you suggest.

KML's approach to content representation is to just carry the content encoded elsewhere. The Schema tag introduced earlier in KML has been deprecated and superseded in KML 2.1 by the Metadata tag. The Metadata tag simply allows any content to be included.

Styling at OGC means to apply rules to geographic content to generate a presentation. There is no such functionality in KML.

This is in no way a deprecation of KML - far from it - but KML is not at all inconsistent with existing OGC specifications. Harmonization at the OGC will thus be fairly straightforward process both for Google and for the other OGC members.

Paul Ramsey said...

I don't know Ron. KML holds content (shapes and information about those shapes) and it has rules for coloring those shapes. Call me simplistic, but if it walks like a duck and quacks like a duck...

I, for one, welcome our new Gooey masters.

Chris DeJager said...

I tend not to get into the nuts and bolts of the encodings but rather keep my head up to see what it all will mean.

If you haven't seen the EPCI 2015 video I highly recommend it, http://epic.makingithappen.co.uk/ . As far as what this may all mean to the geo-community going forward it does paint a compelling portrait. Agree with it or not what we see with KML and the comments on convergence of encoding takes us in the movies direction.

Andrew Turner said...

Interestingly enough, the process finished today. So "a little less than a year" actually means 363 days.

About Me

My Photo
Victoria, British Columbia, Canada

Followers

Blog Archive

Labels

bc (37) it (29) postgis (19) icm (11) video (11) enterprise IT (10) sprint (9) open source (8) osgeo (8) cio (6) foippa (6) gis (6) management (6) spatial it (6) enterprise (5) foi (5) foss4g (5) mapserver (4) outsourcing (4) politics (4) bcesis (3) oracle (3) COTS (2) architecture (2) boundless (2) esri (2) idm (2) natural resources (2) ogc (2) open data (2) opengeo (2) openstudent (2) postgresql (2) rant (2) technology (2) vendor (2) web (2) 1.4.0 (1) HR (1) access to information (1) accounting (1) agile (1) aspen (1) benchmark (1) buffer (1) build vs buy (1) business (1) business process (1) cathedral (1) cloud (1) code (1) common sense (1) consulting (1) contracting (1) core review (1) crm (1) crockofshit (1) custom (1) data warehouse (1) deloitte (1) design (1) digital (1) email (1) essentials (1) evil (1) exadata (1) fcuk (1) fgdb (1) fme (1) foocamp (1) foss4g2007 (1) ftp (1) gds (1) geocortex (1) geometry (1) geoserver (1) google (1) google earth (1) government (1) grass (1) hp (1) iaas (1) icio (1) industry (1) innovation (1) integrated case management (1) introversion (1) iso (1) isss (1) isvalid (1) javascript (1) jts (1) lawyers (1) mapping (1) mcfd (1) microsoft (1) mysql (1) new it (1) nosql (1) opengis (1) openlayers (1) oss (1) paas (1) pirates (1) policy (1) portal (1) proprietary software (1) qgis (1) rdbms (1) recursion (1) redistribution (1) regression (1) rfc (1) right to information (1) saas (1) salesforce (1) sardonic (1) seibel (1) sermon (1) siebel (1) snark (1) spatial (1) standards (1) svr (1) taxi (1) tempest (1) texas (1) tired (1) transit (1) twitter (1) uber (1) udig (1) uk (1) uk gds (1) verbal culture (1) victoria (1) waterfall (1) wfs (1) where (1) with recursive (1) wkb (1)