Update: I made the example a little more clear by pulling the filter out of the wfs:Query.

In a previous post, I wrote that a more RESTful WFS should never accept POST as the HTTP method for a query. Well then, what to do about huge filters? IE limits your GET URI to 2K characters, and Apache will handle only up to 8K. A WFS filter containing literal geometries (like 1:250K boundaries of Norway -- potentially megabytes of fjords) could be many times larger than these limits. So, POST them, although it would be a shame to have to send the filters again for another request?

No. Posting a query destroys the uniform interface, and should only be done if there is no other option. In this case, there is another option, and a fine one: implement filter resources subordinate to feature type resources. The filtered type could then be accessed in the same manner as the feature type itself. The URI:

/places

is a feature type, and:

/places/filters/asdf

would be a subordinate filtered type. You'll recognize that this approach is not very different in concept from a Technorati watch list or a Google custom search engine.

  /places/filters/21f10d70b724f5215cb183d96f27053e/features?type=High+School

  /places/schools?type=High+School

XLink is part of GML, but I've never seen a WFS return GML that links to other resources. Does anybody use GML like this, and what client would they use?

REST and GeoRSS may be alpha-geek stuff and not quite yet ready for the masses, but, Ed, you're not helping when you frame them as lite technologies (emphasis mine):

It's not difficult to appreciate the problem, REST based interfaces, KML, GeoJSON, GeoRSS etc might actually be the best technologies to use today and would be the tools of choice of many, however like many other Government IT projects INSPIRE needs to follow the low risk route of SOAP, WSDL, WMS, WFS etc.

So we may find that organisations will use OGC style interfaces to communicate to other public sector organisations and the commission, while using lighter weight technologies to publish information to their citizens. This is no bad thing !!

HTTP REST is not about light weight (RFC 2616 is just as heavy as a WxS spec), it's about working with the grain of the Web.

The final paragraphs of Ed's (excellent, despite my one quibble) post hint at the biggest risk from using SOAP and WxS:

I am however disappointed by the continued focus on metadata driven catalogue services as the primary mechanism to find geospatial data, I don't believe this will work as nobody likes creating metadata, and catalogue services are unproved.

INSPIRE needs GeoSearch !!

Agreed. Service and data discovery is seriously hindered by the fact that SOAP and WxS services aren't of the WWW.

Update: I just received a reminder that numpy.asarray doesn't copy data.

Here's an example of using Shapely to connect OGR data sources to Matplotlib:

import ogr
import pylab
from numpy import asarray
from shapely.wkb import loads

source = ogr.Open("/tmp/world_borders.shp")
borders = source.GetLayerByName("world_borders")

fig = pylab.figure(1, figsize=(4,2), dpi=300)

while 1:
    feature = borders.GetNextFeature()
    if not feature:
        break

    # Make a Shapely geometry from exported WKB
    geom = loads(feature.GetGeometryRef().ExportToWkb())

    # Wrap the geometry in a Numpy array, slice out lat/long, and plot
    a = asarray(geom)
    pylab.plot(a[:,0], a[:,1])

pylab.show()

The result:

I hope you'll agree that this is considerably simpler than the code I used at the 2005 Open Source Geospatial workshop. An even more direct solution for ogr.py fans would be to provide the Numpy array interface directly from OGR geometries.

body_html_template

So, everybody has linked to Bruce Sterling's recent piece for Wired, but it seems like nobody agrees with me that the best part is right at the top where he sends up geobloggers and the way they (in the future) shill for shiny toys:

My new Sensicast-Tranzeo 3000 is everything palmtops and cell phones have been struggling to become. I can already feel this device completely changing my life. And a wireless consortium pays me to promote it! You should buy one right now. See that handy link there? Did I mention the free shipping? This mobile is so location-aware, it can ship itself!

I wonder if Sterling isn't reading Planet SpaceNavigator/N95/iPhone.

Interest in WFS for Zope/Plone is rising again. The happy future I envision for geographic computing in the digital humanities is more RESTful than OGC, but I still need to provide a way for people to get Pleiades places into the desktop GIS that they bought and installed within the last few years. For now that's WFS, though I expect we might also make shapefile snapshots for people on legacy systems.

I've identified a veritable continent of common ground in Zope for services that I consider to be otherwise orthogonal: WFS and the Atom Publishing Protocol (APP). We Zope users routinely use containers (think of a container as a dict or hash) to model our information systems. In this design, a container full of geo-referenced content, like "places", becomes a WFS feature type or an APP collection. Some such containers are aggregated in yet another, like "root", which becomes a WFS or APP service.

For APP, we register an atomserv view on the outer, service container, and an atom view on the inner, collection containers. These views return APP service and feed documents. Add HTML (and perhaps JSON) views of the collection items, and you've got a geo web service that also happens to act a lot like a web site. Every resource is directly addressable.

WFS is RPC, and has no surface, but rather an endpoint. That endpoint is entirely implemented by the wfs view registered on the outer, service container.

Below the views, there is a big potential for sharing and reuse of interfaces and adapters. I envision that all these views will be acting upon the same IGeoService, IGeoCollection, IGeoItem, and IGeometry.