If you’re anything like me, you’ve been squirreling away useful Shapefiles on your hard drive for years. Maybe even carefully organizing them to the point where you have a multi-gigabyte personal geodata library close at hand. Well, I’ve just started noticing that I’ve been adding WMS Capabilities documents to my library, beginning to count on these services being reliable and ready.
The idea of having an XML document that resembles a static map, but also has links to dynamic geographic and multi-media content is not new. Around 2000 to 2002, OGC worked on strategies for drawing and writing on imagery, and encapsulating geodata along with geo-referenced notes, emails, web pages, etc. These activities produced documents on XML for Imagery and Map Annotation (XIMA) and the Location Organizer Folder.
For various reasons, this work lay dormant for a long time. More recently we put together an XML document format for saving the state of Web Mapping Services–their layers, styles and extent. This is called a Web Map Context Document (WMC) (also check out the XML examples here). This was well-received, and led naturally to the desire to reference more services, like WFS and WCS, in there as well. This more powerful document is being called the Open Web Context Document (OWC).
So somehow the ideas behind OWC and KML have some kind of future together. Probably in a suite of versions. Someone recently mentioned the idea of having profiles of KML–small, medium and large perhaps. Small might be for web browsers, medium might be targeted at thicker clients like Google Earth, and large might be the full-powered, OGC service enabled version that the professional GIS community gravitates to. Only time will tell…
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!
