GData is AtomPub, more or less. The GML and GeoRSS namespaces appear in the examples. Have I ever mentioned that I think it's extremely interesting and significant that Google isn't using WFS-T as a gateway for geo-tagged Picasa items?
At the 2006 Plone Conference sprint, Shaun Walbridge and I wrote a Quadtree-based spatial index for Plone. Unlike the portal catalog, it was a localized index, turning a Plone folder of georeferenced content into a shapefile of sorts. It was a nice proof of concept, but was limited by lack of persistence. A few months ago Howard Butler made it possible to persist Rtree indexes on the filesystem, and last week I finally made the time to rewrite the original Plone product into a persistent R-tree index for Zope/Plone data.
SpatialIndex keeps its original design. Adapting a Plone folder to Products.SpatialIndex.interfaces.ISpatialIndex creates an index on disk alongside the ZODB data, with a name that corresponds to the folder's physical path. Content objects can then be adapted to Products.PleiadesGeocoder.interfaces.IGeoItemSimple and added to the index. Ultimately, the index may be queried for the records of items that intersect with a bounding box. The capabilities are summarized in the session below, using a parks folder that contains a lee-martinez document:
>>> parks = app['plone']['parks'] >>> document = parks['lee-martinez'] >>> from Products.SpatialIndex.interfaces import ISpatialIndex >>> index = ISpatialIndex(parks) >>> from Products.PleiadesGeocoder.interfaces import IGeoItemSimple >>> geoitem = IGeoItemSimple(document) >>> geoitem.setGeoInterface('Point', (-105.08442, 40.59512)) >>> index.add(geoitem) >>> hits = index.intersects((-106, 40, -105, 41)) >>> [h for h in hits] [('lee-martinez', (-105.08442, 40.59512, -105.08442, 40.59512)]
SpatialIndex depends on
You should get PleiadesGeocoder 1.0a1 and SpatialIndex 1.0a1 from the repositories:
$ svn co http://icon.stoa.org/svn/pleiades/PleiadesGeocoder/tags/rel-1.0a1\ PleiadesGeocoder $ svn co http://svn.gispython.org/svn/primagis/SpatialIndex/tags/rel-1.0a1\ SpatialIndex
Additionally, SpatialIndex provides a yet-under-construction index management view through which you count the indexed items and reindex folders, and another public view (@@spatialindex) that can be used in various custom forms and pages.
The switch to OpenLayers is complete. Kai's original map interface was fine, but there are far more resources going into OpenLayers development.
I finally implemented lines and polygons in our PleiadesGeocoder software not so much for display of ancient roads as for making georeferenced feeds that show where we will have new data coming online. Here's an example feed and map, and a snapshot of the KML in Google Earth below:
Also new is a form for setting the location of any Plone content. Location is still stored in GeoRSS (Simple) form in PleiadesGeocoder (mostly to delay content migration), but the form takes GeoJSON. The new code I'm working on for Plone will be storing locations as GeoJSON geometries.
After we get a few bugs out, this will be released as PleiadesGeocoder 0.7 for Plone 2.5, and I'll get back to work on the next generation for Plone 3.
Am I ever glad I took a pass (sorry, Tom) on coming down to Huntsville for this. I suppose this is the Bizarro version of Damian Conway's preach-to-the-choir FOSS4G keynote: telling the overdogs of the military-industrial complex (who, when you think about it, have a financial stake in global trouble) exactly what they want to hear.
I didn't know that OSM covered the Fort. The city gives away street data, and that appears to be the primary source, but somebody has added the Spring Creek and Mason bike paths, the bike extension of Centre through the CSU campus, the bike path from the library to the Meridian/Plum intersection (along which I tow my kid to daycare), and the path around City Park Lake. One of these days, I'm going to get off my butt and help out with OSM.