I read Andrew Hallam's post about REST Abuse last month, and nodded: right, REST != not SOAP. There's more to it. I've spent the past two days programming WMS and WFS clients, and have a little more to add to his thread.

Look at the specs and you'll see that WMS and WFS are aimed at a number of possible distributed computing platforms (DCP). For the enterprisey there is a SOAP DCP. Operations which can't or won't enter the 21st century could use a CORBA DCP. Howard Butler might be willing to scope out an ICE DCP for you. The one DCP you're going to encounter in the wild is named HTTP.

Pleiades uses JSON when transporting map contexts and map features from Plone to our OpenLayers-based javascript applications. Our evolving flavor of geo-JSON is documented in the Pleiades wiki. I'm curious to find out if anyone else is doing something similiar.

Autodesk has one. Now ESRI has its own. Who will be next?

Last week I made new releases of PleiadesGeocoder and PleiadesOpenLayers, the software that's providing the geo capabilities of the Pleiades Beta portal. I haven't been doing the best job of explaining the software, and people -- particularly those familiar with byzantine open source GIS software -- may have misconceptions about the complexity of these Plone products. This stuff is dirt simple. PleiadesGeocoder (soon to be renamed to PleiadesGeo) allows you to annotate Plone content with georeferencing, and provides XML feed-like views of that content for consumption by geographic and mapping applications. The geo-annotations are inspired by EasyCommenting and PloneGoogleMaps (two interesting projects in their own rights), but the views are original.

What makes it all hang together? Reliable Zope 3 machinery and standards. The Pleiades products use Five, so configuring the geo-annotation of your custom content types is only a matter of adapting to IGeoItemSimple and registering your adapter with ZCML. KML and GeoRSS aren't my favorite languages in the world, but they certainly have momentum and plenty of application support. Combining GeoRSS with Atom works well for me, and will be fully supported in OpenLayers 2.2.

Congratulations Russ, Jean, and crew! Check out the lower right corner of this map. Does this officially make I-cubed the biggest little Mom-and-Pop shop yet?

BTW, that's the Fred Hutchinson Center, site of the upcoming Plone sprint.

One of the issues that's complicated all-out integration of Zope/Plone and GIS is the lack of spatial indexes for catalogs. Without an index, your data is bottled up in the ZODB. "Find all features within [bbox]" is O(N), and unfeasible for large sets of features. Pleiades needs to overcome this issue soon, and so I've done something about it.

After researching trees of all kinds and reviewing a number of libraries, I finally went with what had been right under my nose all along: the quadtree from the venerable and inscrutable shapelib. A few years ago I would have used SWIG to wrap shapelib's tree, but I honestly don't give a damn about anything but Python these days. I whipped up tests, a Python C extension module, and Quadtree was born.

How does it work? Check out the doctests:

Make an instance

  >>> from quadtree import Quadtree
  >>> index = Quadtree([-180, -90, 180, 90])

Add 3 items

  >>> index.add(0, [-106, 39, -105, 40])
  >>> index.add(1, (-100, 25, -95, 30))
  >>> index.add(2, (40, 50, 45, 55))

Find likely items

  >>> [n for n in index.likely_intersection([-110, 30, -100, 45])]
  [0, 1]
  >>> [n for n in index.likely_intersection([10, 40, 40.05, 60])]
  [2]

We get a hit for the next bounding box even though it doesn't explicitly
intersect with the item -- it does intersect with the tree node containing
the item.

  >>> [n for n in index.likely_intersection([-110, 35, -108, 45])]
  [0]

How well does it work? I've yet to script runs over the entire parameter space (data density, tree extent, query box size, maximum tree depth), but have preliminary results from tests/benchmarks.py. 1000 points are randomly sprinkled in a box bounded by [0, 0, 1, 1]. The "brute force" method of determining whether a point is inside a box is:

p.x >= minx and p.x <= maxx and p.y >= miny and p.y <= maxy

A typical result, averaged over 100 passes:

1000 points
Index extent:  [-180, -90, 180, 90]
Query box:  [0.2, 0.3, 0.3, 0.4]

Brute Force:
15 hits
1539.89 usec/pass

Likely Intersection:
23 hits
42.03 usec/pass

Likely Intersection with false positive mop-up:
15 hits
115.35 usec/pass

Making one extra swipe over the likely points in order to mop up the 8 false positives is costly, but is still much faster than comparing each point to the query box. I knew it would be, but it's always encouraging to see the numbers.

Speaking of the way I used to do things ... as recently as May I would have rolled this into the Python Cartographic Library, but have seen the light since then. There's been more interest in OWSLib since I dredged it up from PCL. I'm also inspired by geopy, the single-minded library for accessing geocoding services. Quadtree will be similarly single-minded. It depends on nothing except setuptools (for now). After a little more testing, I'll upload to Cheese Shop.

If it looks useful to you, grab via Subversion:

svn co http://icon.stoa.org/svn/pleiades/Quadtree/trunk Quadtree

and take it for a ride.

P.S. -- five quatloos for the first person to find the Neal Stephenson reference in this post.

There's a push to update the MapServer stack in Debian unstable, including MapServer 4.10 and GEOS 2.2.3. Since switching to Ubuntu I'm paying much closer attention to the process. If you're interested, you could help test the packages.

It's two weeks to the Plone Conference. I missed out on FOSS4G, so this is my big conference of the year. Interest in the post-conference sprint is huge. It looks like we're going to have 8-10 people on the geospatial track. Con Hennessy is coming in from Dublin, Kai and Lexi from Helsinki, Chris, Shaun, and Josh -- the usual suspects. I'm expecting at least two new folks, and maybe more. Geospatial, GIS, Neogeography -- whatever you want to call it -- is so hot these days that we might even be able to lure in some of the core Plone developers. Environmental organizations and consultants are well represented at the conference, and get the significance of integrating Plone and GIS. I'm pretty sure we'll be having a Geospatial BoF as well, and discuss the usual issues: data, formats, standards, services, GeoRSS, and KML.

I just like Atom better. One single namespace (plus GeoRSS makes two), and distinction between full and partial content won me over. Hopefully I can pull this off without flooding Planet Geospatial. All my timestamps are OK, so if anything goes wrong I blame James and Mark Pilgrim's FeedParser. I've switched Pleiades over to Atom as well (example: bridges), and contributed a patch to OpenLayers that enables mapping of Atom feeds.

Update: the old RSS feeds are going away forever. Switch over (entries, comments) if you want to keep following this blog.

Update: I did everything right and still flooded PlanetGS. Makes me much more forgiving of the folks upgrading their Blogger accounts.

Update: I added the missing rel="self" and rel="alternate" attributes to feed and entry links.

The shift is well underway. And I, for one, welcome our new open source overlords.