Report on the Where 2.0 OGC BirdsOfaFeather (BOF)

We had a nice group of about 15 at the OGC BOF at Where 2.0. Unfortunately, we were programmed at the same time as the OSGeo BOF, so a lot of the developers most active in lightweight OGC services like GeoRSS GML and WFS Simple (soon to be rechristened as GeoQuery Service as it moves towards 1.0, but more on that later) couldn’t be with us. Still, we were able to hit a couple GeoRSS issues and delve into other areas.

At one point we got into the issue of representing a single object that has different geographic locations at different times–like an airplane or a ship track. This was a big mailing list discussion earlier in the year, but I don’t think anyone mentioned the fact that Atom has an official way of handling this. If you look at the description of the <id> element in an <entry>, you’ll find this:


Two entries in a feed can have the same value for id if they represent the same entry at different points in time

So as long as <entry>s have the same id, you can change the time, geography, etc., and readers should consider them to represent the same object in different states. Sound like what we’ve been looking for?

On the WFS Simple/GeoQuery Service front, everyone seems happy with the basic data access proposal, but need more query support than time and bounding box. The general consensus from this group and various emails and site comments is to go with regex as a query language, but to NOT have XPath expressions. The thinking here is that XPath queries go too far towards requiring a certain level of XML representation of one’s data on the server, which is a much larger hurdle to adoption than simply outputting XML after a query has run in the database. A quick survey of the attendees felt that all the major databases out there had regex support, including Oracle, DB2, SQL Server, MySQL and PostgreSQL. Programming languages are all covered too.

You may be wondering, why yet another name change? We’ve already gone from WFS Basic (which was confusing because the WFS spec calls its HTTP GET profile WFS Basic) to WFS Simple. The reason is because there was a feeling at the last OGC Mass Market Working Group meeting that a service that did not require GML output should not be called WFS anything. This is a good point as the word Feature means something very specific in OGC terminology, and this service does not necessarily return features. I think it’s a “good thing” to not confuse the market by having a WFS service that doesn’t return GML, so barring something drastic–like someone has already used the term, WFS Simple is now GeoQuery Service.

So in upcoming weeks look for a new GeoQuery Service site on OGC Network with pages for Atom/GeoRSS queries (GQS-Atom?) and a “pure” RESTful approach to geodata query that Chris Holmes of GeoServer is cooking up.