Geometries for Python Update
Update (2008-01-21): See http://pypi.python.org/pypi/Shapely/1.0.
An older, slightly outdated, post of mine about Python geometry packages is getting read enough to warrant an update.
Geometries from mapscript.py and ogr.py haven't changed in the past year. The GeoDjango developers are finding that the geometry API in geos.py isn't so bad -- perhaps because they're doing the bulk of their operations and transforms within the database -- but the fact remains that the GEOS project is trying to deprecate use of the C++ API, and that this puts geos.py in some peril.
Since the Python Cartographic Library's 0.11 release, geometries are now a part of the PCL-Core component's cartography.geometry package. Howard Butler added pickle support, and we've fixed a number of bugs since the start of 2006. We've also reduced the dependencies of PCL-Core, as you can see in INSTALL.txt. Remember, "zope" is now a namespace package, and you can install zope.interface [Cheeseshop] separately from any other piece of Zope 3.
I have nothing to report about FDO's brand new geometries for Python. My understanding is that they are also based on GEOS.
Comments
Re: Geometries for Python Update
Author: Allan
The thing that stopped me from going much further with GeoDjango was the need for GEOS. As far as I could tell with the version I had, GEOS was just being used to pack/unpack WKBs. PostGIS can do that already so I wonder if it would be possible to use WKT on the GeoDjango side instead of WKB. Unfortunately, trying to install GEOS with Python bindings on Mac OS X was just too much for my meager abilities. However, I realize that it's early days and I'm not complaining. I think it's great that you guys are working on this.Re: Geometries for Python Update
Author: Rob
GeoDjango will always need to depend on something (eg. GEOS) otherwise it forces the DB server to do a lot of work. GeoTypes can be a python-only parser for WKB, but then you still are without a solution for geometric operations (area(), length(), x(), y(), transform(), ...) so you end up back at GEOS. My research has also turned up OGR's python bindings which are both maintained, and have no dependencies except OGR itself. Experiences? Comments?Re: Geometries for Python Update
Author: Jason Birch
Heh. Well, FDO's Python wrappers build on Linux now, so that's slightly new... I could be wrong, but to my knowledge GEOS is not used by FDO at all (it is by MapGuide). It might would be a good idea for FDO to use GEOS to provide some more advanced spatial processing for providers that don't offer it natively. For instance, the MySQL provider is limited to envelope operations. But maybe people using MySQL are OK with this :) JasonRe: Geometries for Python Update
Author: Sean
Like I said, Jason, I'm ignorant about FDO geometries and had nothing to report. Rob, if you go back through my previous post, you'll find out everything I know about ogr.py's geometry API.Re: Geometries for Python Update
Author: Matt
I was also having problems with GeoDjango and the geos dependency on my intel mac but I managed to get it working with the r5008 update and manually setting my lib_name = 'libgeos_c.dylib' in django/contrib/gis/geos/GEOSGeometry.py. The original value in that file points to a library that doesn't exist on mac when you build geos 3.0.0RC4 but the older version of libegeos seems to work.Re: Geometries for Python Update
Author: Sean
The ctypes-based geometry module in r5008 looks kickass. I'm checking it out now.