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.

About rajsingh

I'm on the staff of the Open Geospatial Consortium and still spend time hanging around the MIT Dept. of Urban Studies & Planning, where I did my graduate work. However, whatever you find here is solely my own opinion.
This entry was posted in georss, mass market, wfssimple and tagged , , , , . Bookmark the permalink.

7 Responses to Report on the Where 2.0 OGC BirdsOfaFeather (BOF)

  1. Jason Birch says:

    Hmm.

    Are you sure that this functionality wasn’t intended solely for revision tracking?

    I’d really hate to have to post the same entry multiple times just because it talked about the multiple locations that I’d visited in my fictitious sailboat today.

    I see the geography attached to feed items as decoration for the article; a way of providing context, in the same way as an image or a graph would. Breaking this illustration aid across multiple entries just doesn’t feel right to me.

    Of course, I’ve been wrong before… but please don’t tell my wife :)

  2. rajsingh says:

    Good point. What I describe would certainly be overloading a system that had another purpose, but I don’t think it overloads any worse than the other ideas for representing an object moving over time.

    None of this space-time stuff will probably ever be parsed by standard feed readers in a really intelligent way, so my preference would be to, at some point, drop the RSS fiction and work on lighweight geo encodings for a client-platform-to-be-named-later.

  3. Chris Holmes says:

    I still find regex very weird for the query language. It’s very much a programmer thing, and not even a basic programmer thing at that. I think using the Common Query Language is a much better choice: filter=’treeType like elm AND num_branches > 5′. It’s much more intuitive and ends up being a lot more powerful.

  4. rajsingh says:

    Hmm. I like that too, and it already solves the problem of specifying the field you want to apply the query to. You should post this to the list.

  5. rajsingh says:

    And why is my server host on GMT time? I’m pretty sure the machine is in the US?!?!

  6. Yeah Chris! This is exactly the point that I made in an editor’s note in the OWS4 WFSS IPR (07-004, now GeoQuery Server IPR I guess). Regex only provides pattern matching capability similar to the LIKE operator in SQL. You cannot base an entire predicate language on regex. CQL is a much better choice and this is what the WFSS IPR proposes.

    On the issue of confusion, do you really think that having a WFS AND a GeoQuery Service will not confuse people? I always viewed WFSS (or GeoQuery Service) as a simpler compliance class for WFS than WFS Basic. I could be wrong!

  7. With regard to the issue of multiple locations for a single object, for me, this is a very real issue. During major mesoscale “storm-chasing” campaigns, we see mobile weather stations moving hither and yon. We need to know where they are, and when, as well as the observed data. In the ocean science/observing community, autonomous underwater vehicles and gliders, as well as floating buoys, will need to report position. Ships providing weather, currents, and sea-surface temperature will be reporting position as well. And, terrestrially, the Forest Service has fire-weather reporting platforms that they move somewhat arbitrarily to where they believe the highest likelyhood for fire danger is. All of these are real world scenarios.

    So: Has anyone considered how to create a normalized relational database schema to support this? I’ve iterated down several lines and not come up with a good mechanism.

Comments are closed.