2006 (old posts, page 14)

Open Source Proliferation

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


Re: Open Source Proliferation

Author: Frank Warmerdam

Sean, I think ESRI "fell into" this after purchasing the german company that helped found 52 north. I don't know the details, but I'm not sure that this amounts to an intent to support an open source oriented foundation on ESRI's part. I do hope they continue to support 52 north though, as they seem to be doing some important open source work even if part of it is on unpopular topics like GeoDRM. Best regards,

Dirt Simple Geo for Plone

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.

Pleiades Geo

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.

Python Quadtree

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.


Re: Python Quadtree

Author: bryan

It looks like the boxes are defined simply by north, south, east and west limits. Can one define the boxes by providing the full coordinates of the box corners (which is much more useful near the poles)? If so, I'm very, very interested ... Cheers Bryan

Re: Python Quadtree

Author: Sean

We're limited to rectangles, so you only have freedom to choose two corners. That's four bounding values any way you slice it. I chose to follow the lead of the older WMS spec for bbox rather than GML 3 style min and max corner points.

Re: Python Quadtree

Author: Matt

Sean, thanks for sharing this. Throwing together a quadtree module for Python has been on my to-do list for a few months now and I was just getting to it today, perfect timing! =)

DebianGIS, GEOS, MapServer

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.


Re: DebianGIS, GEOS, MapServer

Author: James Fee

Ubuntu? Damn, now you too?

Re: DebianGIS, GEOS, MapServer

Author: Sean

I hardly ever use my old iBook these days. It's going to be a bit of a drag coding on it at the Plone sprint.

Geo at the Plone Conference

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.


GeoSprint at PloneConf 2006

Author: siebo

I'm really looking forward to this sprint, jamming with the PrimaGIS/PCL crew, and meeting you guys in Real Life™.

Switching to Atom


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.


Re: Switching to Atom

Author: James Fee


Re: Switching to Atom

Author: Empty

Would it be possible to put more of your posts in the feed, or atleast show the hyperlinks?

Re: Switching to Atom

Author: Sean

Entry 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.

geopy: Python Geocoding Library

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.