Raj Singh pointed out this document from Nokia on their Landmark Exchange Format Specification. It’s an XML definition for sharing locations between mobile users – originally spec’d September 2005.

This is a really great idea. The doc contains some nice layout of use-cases for mobile users sharing and loading landmarks. I should be able to easily send someone a location, especially my location, our meeting spot, a great hike, or whatever. However, it’s not clear why Nokia defined their own specification. Or at least, why would they continue to push their own specification.

One of the purposes is interoperability – as stated in the specification:

Landmark messaging should work across different manufacturers’ devices. This specification is open and license-free and allows incorporating the functionality to different software platforms and interoperable Java MIDP landmark messaging applications for the devices of other manufacturers.

While the specification is “open and license-free” it is still controlled by Nokia. Look at the MIME-type: application/vnd.nokia.landmarkcollection+xml. What that means is that while you are free to use the spec, you probably won’t have any say in the format if you need some functionality or find a problem.

Now compare to a location-documentation format like KML. Now, to be fair, KML wasn’t as ubiquitous in 2005 (or the year Nokia was probably working on their spec), and the MIME-type of KML is still application/vnd.google-earth.kml+xml. However, KML is now undergoing external standards adoption, and will be outside the specific control of a single entity, Google.

More than just ownership

While allowing community input into a format is nice, there are more reasons to use a more widely used format like KML – namely that it’s more widely used and therefore there are a lot of clients and services that can make use of the format. More players means more fun.

Nokia’s Sports Tracker app does export KML, as well as GPX. This makes it very nice to email, share, and upload your hikes or workouts. Perhaps this is a trial for them. However you can’t load KML into Sports Tracker to follow someone else’s track.

Here’s to hoping that Nokia supports KML and even GeoRSS for subscribing to a source of location information (such as a stream of sensor data or friends’ locations).

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.