Shapely Geometries for Python

Shapely is to be an LGPL-licensed replacement for PCL's cartography.geometry package. Like its ancestor, it will provide familiar geometry classes with all the spatial operators of GEOS. When done, cartography.geometry can be rewritten as a lightweight layer over the new code. Additionally, Shapely will have a more Pythonic serialization story, and plug and play with other powerful Python packages using the Numpy array interface. Last, but not least, Shapely will be much easier to build, install and deploy.

Shapely serializes and deserializes using the familiar idiom from the pickle module. Here's a pickle stream example (an actual project doctest):

>>> from shapely.geometry import Point
>>> import pickle
>>> point = Point(0.0, 0.0)
>>> data = pickle.dumps(point)
>>> pp = pickle.loads(data)
>>> pp.equals(point)
True

Comments

Re: Shapely Geometries for Python

Author: Bill Thorp

Sean, apologies for this aside... Shapely isn't something you're authoring, is it? I've been meaning to write about my love/hate relationship with certain JSON serializations. '{"type": "Point", "coordinates": [0.0, 0.0]}' is a crazy-horrible waste of space, especially when you consider points are part of just about any geometry. I imagine that most JSON geometry serializers act like this. Mine does, with shorter attribute names. Tripling geometry bandwidth is bad, but using custom JSON (de)serializations just for geometry is also a questionable undertaking. I'm torn between thinking this is a case where KISS just does not apply, and questioning the point of optimizing JSON when large geometries are bunk in browsers anyway.

Re: Shapely Geometries for Python

Author: Sean

JSON is but a small facet of Shapely. Yes, the GeoJSON coming out of our working group is a bit verbose. I like my initial {"type": string, "value": array} better. Anyway, reducing bandwidth versus XML isn't my motivator. I want a non-XML data option, to exchange dicts.

Re: Shapely Geometries for Python

Author: Justin Bronn

You'd still need to hack with OGR since GEOS does not read geometries directly from geographic datasets (e.g., SHP files). That's one of the reasons I implemented GeoDjango's ctypes interface for GDAL/OGR (includes a "pythonic" API).

Re: Shapely Geometries for Python

Author: Sean

Yes, you need GDAL to access legacy data. Your GeoDjango package looks good (and I've definitely learned a lot from your ctypes examples), but it's too tied to Django to be useful to me. On closer examination, looks like one should be able to add contrib.gis to python path and import contrib.gis.gdal after all.

Re: Shapely Geometries for Python

Author: Justin Bronn

On closer examination, looks like one should be able to add contrib.gis to python path and import contrib.gis.gdal after all.
Sean, I've tried to ensure that GeoDjango's external interfaces to GDAL/OGR and GEOS were as loosely coupled as possible. As far as I know, both interfaces are completely independent of Django -- the only requirements are ctypes and a compiled C library of the interface.