Last Monday I participated in a Geospatial Search Summit hosted by the OGC as part of the quarterly Technical Committee (TC) meetings. The TC’s are primarily about various working groups discussing progress and status of standards or interoperability demos.

By comparison, this summit was meant as a brainstorming around geo and search interfaces and responses. Pulling from the announcement:

We would as much as possible like to bound the discussion to: 1) common ground for geospatial search for web resources and 2) integrating spatial search into search protocols. As part of the discussion we would also like to get advice from the other communities about which catalog/registry search protocol is the ‘mainstream’ one (or more?) that we (OGC) should align with and in turn, be sure that spatial search is supported in a thoughtful but not cumbersome way by the broader IT standards community.

You can see a partial list of attendees here.

There was a good overview of existing, albeit often quite complex, search interfaces. As is potential in meetings like this where attendees have their own history, investments, and beliefs in standards, the discussion can become difficult to easily resolve.

A couple of interesting agreements came out of the meeting. Foremost was the understanding for guidance of using simple, common formats as they already exist when appropriate. This means using OpenSearch as a base URI templating mechanism and follow GeoRSS-Simple specification for geographic data. Of course, a format can expand upon this and offer more complex formats that conform to more complex specs. But by at least providing a common baseline means that almost any service can easily interconnect with another service.

One difficult mechanism that is missing is a way for geographic search to specify the type of spatial operation. Typically most services assume a “within” or intersects”. For example, what restaurants are within a 5-mile radius of my position. However, it’s apparent that this can be confused based on assumptions and also does not provide for any other type of operations. Again, for example, find me all the hospitals that are not within the hurricane path.

A long-standing model for this is called the DE-9IM spatial operation set. It was presented by Eliseo Clementini, and also frequently attributed to Egenhofer. You can read more about it. Granted, a majority of geospatially-capable search interfaces may not require this, but it’s nice that there is a relatively straight-forward model that everyone can agree on.

I hope more attendees share their thoughts and outcomes. There are definitely many who point out the problems of designing standards in a smoke filled room, and I much rather bringing the discussion out into the open where more people can chime in and contribute.

GeoRSS has gained a lot of popularity and has recently shown up in some user tracking applications like Dopplr and Plazes. This means you can drop the feeds into your feed reader - or GeoRSS widget or aggregator to mix in your friends’ or family members’ locations with your other feeds.

However, once you pull the feed out of the original service, you should being to wonder about the privacy. Many of these services required authorization before allowing you to pull down feeds. This way they can make some assurance that only allowed people can grab your location feed. However, once the feed is pulled out, it is out of the hands of an authorization system and has a very easy potential to be made unwittingly public.

The onus of security is on the application or aggregator that pulled the feed on behalf of the authorized user. But at the same time once the feed has been retrieved, there is no storage of the authorization credentials with the feed itself. It has essentially been stripped of it’s shell of potential privacy and looking at the feed itself you would have no idea if it was supposed to be kept private, and visible only to certain, unknown persons.

What would be nice would be a mechanism to store at least references to permissions and authorization credentials within the feed itself. That way if an application still has the feed, or wishes to store it and re-aggregate it, they can apply the same authorization as the feed originally had.

Existing Mechanisms?

Brian Suda pointed me to the, currently suspended, Platform for Privacy Preferences. But this appears to be a rather heavy-handed approach. The W3C GeoPriv Working Group is also looking at location privacy but not in terms of feeds, and the idea of permissions and privacy aren’t specific to location (though that is typically where it gets a large amount of attention).

Simple Soutions

I’m wondering if there exists, or could easily be formulated, an additional markup in Atom to specify permissions. It would still be the responsibility of the application to abide by these permissions - but at least they would have the information necessary to do so.

Here is a possible solution. Provide a default access (private), but then refer to authorization endpoints for who would be allowed to view this feed. In this example, if the user can provide OpenID authorization to this URL, then they can view the feed:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" >
   <title>Andrew's location</title>
   <permissions>
     <default access="none"/>
     <permission access="view" href="http://myopenid.com/bobdingle" type="openid"/>
   </permissions>
   ...

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.