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.
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])]  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])] 
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: 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.
Re: Switching to Atom
Author: James FeeSigh...
Re: Switching to Atom
Author: EmptyWould it be possible to put more of your posts in the feed, or atleast show the hyperlinks?
Re: Switching to Atom
Author: SeanEntry links are coming through loud and clear on my readers (NewsFire and Thunderbird). Or at least I thought they are. I've 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.
This morning Howard alerted me to a new release of geopy, the Python package that provides a uniform API to a number of free (beer) geocoding services. I like the API and it has more features than what I'd previously written for PleiadesGeocoder, so I ripped out the guts of the Plone geocoding tool and swapped in geopy. My tests pass and I'm quite satisfied that this is a beneficial dependency for Pleiades. I like geopy so much I just sent the author a patch that adds doctests.
Chris and Schuyler's rectifier is triggering flashbacks to my days as an apprenticing image analyst.