I’ve been waiting for the dust to settle on a few things before posting this entry. Many people are aware that KML is in the OGC standardization process in OGC now, and that became official at the latest OGC meetings in April. Paul Ramsey and Carl Reed have some insights into the process up to that point. Here I’ll give my take on what is happening for the rest of the year, and give some sense of how I see the process taking shape.

First of all, there’s a widespread misconception that KML is a data format. This viewpoint doesn’t do justice to the complex problems geospatial data encodings solve, and just as importantly sells short the elegant way KML tackles a different need in the market. I think of KML as modern cartography. It’s a mixture of data, styling, and interactive hypermedia. KML does a nice job of blending the Web with geographic information systems, but you wouldn’t want to design your information management strategy around it. But it is a great way to encapsulate a view of the world in a lightweight, easy-to-share, file format. Much like cartographers used to take their vast knowledge of place into a well-designed map, from those beautiful old maps we all love to the USGS 7.5-minute quadrangles that were the workhorses of US mapping for decades. My hope is that widespread adoption of an international standard KML will further catalyze the renaissance in mapping that Google Earth started, but this time everyone can participate.

So how do we get there? First of all, KML is a highly successful format whose design and features have been proven in the pressure cooker of the marketplace. We do not want to damage that legacy. This new OGC Best Practices paper lays out KML 2.1 as the basis of our work. None of the KML is new, as it is exactly what is shown on Google’s KML Reference. The important new thing is the preamble, which lays out the primary areas in which we are interested in adding new functionality to enhance KML’s interoperability with OGC’s standards baseline. These include more flexible data access, such as adding some kind of dynamic geographic feature request, probably via a WFS interface; updating KML’s geometry to a limited subset of GML 3 (GeoRSS GML? GML Simple Features?); and finally figuring out where Context stops and KML starts.

Unlike most OGC standards development processes, we’ve realized that KML evolution must start out open to non-members to do justice to the existing developer community. There are many ways to participate is this worldwide discussion. The most basic is to subscribe to mass-market-geo mailing list. This is a moderated list with low traffic (at the moment). I also have a feeling that there will be a lot of KML discussion on OSGeo mailing lists, the GeoRSS list, and or course, Google’s own forums.

The OWS-5 Testbed has a thread devoted to experimentation with KML, and is designed to spur the development of new tools to create and share these new experimental versions of KML. For those unfamiliar with OGC testbeds, they offer a forum for developers to collaborate on the design and architecture of emerging technologies in the geospatial field. Many participants receive funding to participate, but this should not be seen as a profit-making activity, but rather a way to offset R&D costs. OGC staff works hard in the testbeds and discussion groups to facilitate the conversations and development efforts so that everyone’s time is used most efficiently and the best ideas rise to the top, no matter how large or small the company or person is who had the idea. So please join us in one or all of these venues and contribute to the year of KML!