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!

In the OGC meetings last week WFS Simple was presented to the membership as a part of the “OWS4 GeoDSS Mass Market (formerly GeoRSS) IPR” (note this link will only work for OGC members for a few more days). It was approved as a discussion paper, which is a document that’s worth making public, but is not necessarily an “official” position of the OGC (as a Best Practices paper is).

There were two major areas of discussion at the meeting. One was around whether WFS Simple should harmonize with WFS and become the most basic WFS implementation. The other was related to Basic XML Feature Schema (BXFS) as the default output schema for WFS Simple. These are actually related items as the biggest problem with rolling WFS Simple into WFS would be the issue of having GML as a required output format.

Although at first blush it sounds nice to bring this work into an existing service, I agree with the opinions that it should stay separate. GML as a required output format is too important of a foundation of WFS to tinker with. Therefore I propose maintaining the separation and pursuing the following work items leading to a 1.0 specification.

1. keep WFS Simple focussed on being the generic geospatial data query language for mainstream web data formats like Atom+GeoRSS, KML, etc.

2. Componentize the design of the service, so that this is not really one service, but a simple, clear way to design services focussed on a particular data type like Atom+GeoRSS by adding or removing a parameter or two.

3. Re-emphasize the separation from WFS by moving towards a 1.0 specification with a new name, Geodata Query Service

The big news of the week was Microsoft Virtual Earth’s announcement of a new version of Live Maps, and Google following days later with a new feature called My Maps. These are both ways, put simply, to do heads-up digitizing in a Web browser!
The importance of this is development is hard to exaggerate. For years the consumer marketplace has done street mapping extremely well. But that was just streets. “Real” GIS folks need to overlay data from various sources, right? Then last year OpenLayers let you have the best of both worlds, overlaying any arbitrary WMS on top of a Google Maps base map. With the merger of OpenLayers and Community Mapbuilder, expect to soon see a Google Maps base map under your choice of WMS and WFS services and/or embedded GML data, styled with SLD and all wrapped up in a nice KML or Context document.
Add to this the ability to create geographic content in your Web browser and access it via a URL, and a very interesting vision of Web-based GIS begins to emerge. It’s a vision that’s very different from the one the GIS conference circuit has been giving us all decade. I could expound on what I think that vision is, but that’s not really important. The most interesting thing I see here is that the architecture is so beautifully loosely-coupled that there is room for everyone’s vision to be realized. One thing I will predict is that the truly interesting time for Geo-startups begins now.

p.s. Does anyone else find it odd that such a major new feature was introduced by two pretty big companies in the same week? Coincidence, or something else? Please Adena get some dirt on this! inaccurate statement, see comments –Raj