If you’re involved with geospatial technology, you’ve probably at least heard of the OGC. The OGC, Open Geospatial Consortium, is a standards organization that guides, stabilizes, and supports geospatial formats. It’s like the W3C for maps. They’re responsible for formats like WMS, WFS, GML, et al.

I give this introduction because if you’re a neogeographer, or somehow ancillary to traditional GIS, then you may not really know what the OGC does or how it operates. From my experience, and the crowds I hang out in, the OGC is a mysterious entity that rains down schemas and complex formats. One major problem, in my opinion, of the OGC is that it requires membership to join or participate, and sometimes to even view working documents, and membership requires sums of money (amount depending on the size of your organization). So if you use geospatial standards, but not heavily invested in formulating new ones, you’re kind of left out in the cold to wait and see what emerges from these ’smoke filled rooms’.

Therefore, it was interesting to see that Google decided to ‘open’ the KML format by submitting it to OGC for standardization and further development. By moving the format outside of itself, Google assumedly hopes to gain broader acceptance of the format so that other companies and software feel more comfortable implementing KML and also possibly guiding its future development.

Organizing Geospatial Committees

OGC itself is really just an administrative organization. By itself the OGC doesn’t actually develop and implement standards. Instead, it coordinates the activities of companies and developers to do this. Technical Committees (TC) are formed from OGC Member organizations that meet regularly to discuss the standards, and then develop reference implementations of these standards. For fairly stable formats, such as GML, this is done incrementally.

However, when a sponsoring organization (OGC member that pays a lot of money) has a particular task they would like completed, a Testbed is formed that will more quickly, and focused, develop aspects of a standard. This is the case with Google and KML. They would like the OGC to quickly discuss and adopt KML and move forward on future directions that KML will take. And then they would like several organizations to develop example, or reference, implementations of KML for publishing and consuming to exercise the standard (and find any little bugs along the way).

The OGC lumps several of these tasks together into a larger OGC Web Services Testbed, or OWS. The newest one is the OWS-5 testbed, that involves several ‘threads’, one of which is “Agile Geography”. It is this thread that includes the task to adopt and advance KML.

Raj Singh, Director of Interoperability Programs at the OGC gives a great introduction to KML as part of the OWS-5 testbed.

Enter the fray

So… Why am I going into such depth on the OGC? Our newest venture, Mapufacture, was selected to participate in the Agile Geography thread of the OWS-5 testbed. In particular, we will be implementing KML 2.2 and also moving forward on many aspects of advancing KML to better operate with other standards such as GML and WFS (heavy-weight), as well as express the interoperability with lighter-weight standards such as GeoRSS and OpenSearch-Geo.

But I also have another goal. Having been an outsider of the OGC and the standardization process, it has seemed like an opaque operation that is disconnected from the emergent and dynamic geospatial web. If you’ve dealt with any of the standards before you too may be frustrated by the silent communications, the thick (hundreds of pages) PDF documents behind click-through licenses, and obscure explanations and esoteric formats.

So my goal is to make my participation in the process as transparent as possible. As part of the thread, we are going to share our conversations and drafts along the way to elicit feedback and comments from the broader community. The entire purpose of the testbed is to develop a format that is useable and understandable by people that are not GIS experts – but just want to use the format to express locations and geography as it relates to their non-geo-centric activities. (i.e. someone building a photo-sharing site does not want to read a 400 page document on WFS and then have to deal with 10-level deep XML).

However, I’ve also that there are justifiable concerns with how open the process can be. Intellectual Property rights concerns, and more importantly the concern that unscrupulous types would try to claim-jump formats and patent them for their own nefarious uses exists. This isn’t as much as a concern for KML, which already exists as a format – and we’re making use of other existing formats – so this shouldn’t be as much a concern. But it was enlightening to learn why in the past there has been a somewhat lack of outside communication during a development process. Of course, there was also the somewhat greedy desire to have “first dibs” on formats by being a member.

The kick-off meeting was yesterday and today in Reston, VA where we are meeting with the ’sponsoring organization’ (Google) and the other members of the thread to do general discussion of goals, issues to discuss, and tasks to perform for the next couple of months and over the entire 6-month length of the testbed efforts. I already have several pages of notes on what we’ve discussed, so watch this space for specific requests for feedback on the updates to KML. I’m looking forward to sharing the experience of developing a standard and how the inner cogs of the OGC operate.