Designing Simple GIS Services for Zope

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.

http://trac.gispython.org/projects/PrimaGIS/attachment/wiki/GisWebServices/geo-web-services.png?format=raw

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.