Mapping Hacks

Ed Parsons offers an upbeat description of the Open Geospatial Consortium’s “mass market” / interoperability process. As a member of the geolumpenproletariat, I spent some time over the last month or so attempting to engage with the WFS Simple public development process marshalled by our friend Raj Singh. I backed away from it a couple of weeks ago, and wrote down at the time some of the reasons why…

When I heard Raj give a presentation about the emerging WFS Simple specification at the UK Geospatial Mashups event back in October, I was sold immediately. This was the Web Feature Service cut right back to the essentials - bounding box / temporal slice query, simplified keyword query, that’s it. Targeted at the “neogeography” audience, as I perceived it; a good fit for GeoRSS, carrying data around using any number of data syndication formats. I wrote a GeoRSS/RDF aggregator library in python last year and this would be an ideal interface for it. My head also rang with the prospect of using WFS Simple to base a simple metadata discovery service on, very much in the way that Tom Kralidis has done over WFS to produce OWSCat.

Rather than being a formal standards project in which paid membership in the consortium is necessary for participation, Simple’s specification process is being run as part of the ‘OGC Network‘ and actively encouraging open contribution from free software developers. A lot of people from the OSGeo community signed up to the Simple discussion list; there’s a lot of interest in simpler standards to make vector data more distributable.

A few days later I had the chance to sit down and re-write bbox, the GeoRSS aggregator and add a WFS Simple interface to it; i had a lot of questions as a result of implementing what the informal specs described, which got fed back into the docs, and which produced a good feeling.

WFS Simple is directed at the casual implementor not versed in the more traditional ISO or OGC standards, a very selfconscious attempt to “lower the bar”. In this i found it successful; apart from time spent refactoring the original application, it took less than a couple of hours to do everything required in the spec except DescribeFeatureType, which there is still a lot of discussion about omitting or adapting. One viable suggestion of Raj’s is to put the metadata describing the objects in the repository (the features) into the metadata describing what the web service does and who to call about it (the GetCapabilities request).

There are problems with simplicity. Everyone has a different view of the simplest, least useless thing. Mine is pretty expansive; I want to see a way of doing Transactions without having to implement full WFS-Transactional. I reluctantly agree that this is a non-simple request; in which case I want an approved way of extending the query interface and advertising common extensions to it.

Others are particularly interested in the use of WFS-Simple to offer a carrier format of Atom or RSS decorated with GeoRSS and Dublin Core properties. In theory there’s nothing to stop one sending arbitrary formats over WFS proper - GeoServer offers KML and GeoRSS outputs and is planning a JSON output. WFS client support is working to some extent in OpenLayers. But WFS is often too slow to use real-time; there’s more value in a data synchronisation protocol to make local copies for processing purposes, or in a tile cache for many different renderings of vectors as different resolution bitmaps, for web mapping purposes.

I finally unsubscribed from the WFS Simple list yesterday. Not because I’m no longer interested in the protocol and planning to build it into different apps; but out of disillusionment with the discussion process and how the goals are being expressed and met.

I recall an audience reaction to Raj’s presentation at the Ordnance Survey; a meterologist who maintained that the full expressiveness of GML and WFS was necessary for them; they could not be compelled to accept a simpler alternative with less utility. One meme we had way back when writing “Mapping Hacks” was of “locative” vs “GIS” - the long tail, and the high priesthood, and the tendency of the priesthood to look at anything simplified, fuzzily accurate or incomplete, as somehow intrinsically inadequate. There’s also been a long thread about “spatial data infrastructures” vs the “geospatial web”, and how to integrate the two concepts.

I am not a fan of WFS or GML, but recognise there is wide support and a variety of sophisticated use cases which there is nothing else will answer fully enough. But i’m exasperated by the dismissive attitude often displayed by people deeply involved in the OGC and ISO standards processes, to “grassroots” developments formed without the knowledge in that deep involvement. OGC was happy enough to subsume GeoRSS into their own offering once the community had done the work of specifying it, but the RSS and RDF geoannotation work from which it emerged, is bypassed. The rest of this post is most of the last email i wrote to the Simple discuss list, before backing away from the OGCistas…

RSS’s heritage is in the Semantic Web (cf the ill-fated RDF-expressed RSS1, which was forked by Dave Winer into RSS2 over widespread community objections, and Atom was a Sam Ruby-led attempt to close the divide.  GeoRSS is being used to syndicate updates to data sets in public administrations, big publishing organisations, and has extensive support in open source geospatial software projects. It fits a market niche which is even larger than “annotating web pages”. The use of the URI as a UUID for any kind of object is a utility.

Raj’s use case emphasis for Simple Web Feature Services is on non-spatial elements and attributes which are connected to spatial features, coming out of excel spreadsheets, conventional databases, etc.

To me, a web service is a convenient interface to a repository of data and of utilities with which to manipulate it. Web services, while an awful lot better than having to screenscrape and steal data or having no data at all, aren’t “more valid” than having structured data available at a repeatable URI, which has the advantage of being discoverable and indexable by bots. The non-discoverability of OGC web services has led to layers of superfluous registry models, service discovery services, etc, all dancing around the issue of making data available where it can easily be found, repackaged and reused.

The “geospatial web” has been far ahead on “open data” or common structured data in pretty much every domain, including the low-hanging fruit of music and media. Good precedents in open standards and in collaboration between SMEs inside consortia have been set. But if the geospatial standards community continues on this path of isolating itself, of looking upstream to the ISO rather than downstream to the distributed neogeo developer community, it will miss out on being connected to amazing things.

So i’m surprised to see an effort in outreach and interoperability seemingly retreating into itself. I turned up to the WFS Simple development discussion process really pleased to hear of developments on a very simple, very implementable query interface which would generously support a variety of output formats. I’m losing sight of the value a bit now - it’s difficult to see more advantage to this than to, say, adding a bbox query option to OAI-PMH and building services on it; and that’s the path i’m going to follow for a while.

Essentially i want a specification to operate in the way a software project can so well - a small core and confined core, an extensive plugin architecture (e.g. encouragement to extend the query interface for specific purposes like basic transactions or feature/tileset metadata publishing), with every suggestion driven by a test case. I know that what I want for Simple probably falls between two stools - not expressive and flexible enough for the hardcore - not familiar and straightforward enough for the much larger neogeo constituency. Right now the process risks failing both communities and emphasising the difference between them, and that’s an awful shame.

Posted in geodata, services, osgeo |

You can follow any responses to this entry through the RSS 2.0 feed. Trackback from your own site.