Manipulimization of whatchamacallems?
I posted a link to the listing of GIS stuff in the Python Package index the other day and was reminded that there's not quite enough information there for people looking to match their requirements with software. Click through some of the links and you may find no distribution at all, or a dependency on some C library (that would be my work). The descriptions can also be a little vague, such as "Geospatial geometries, predicates, and operations". Click through the accompanying link to Shapely and you get a slightly more verbose description:
Shapely is a Python package for manipulation and analysis of 2D geospatial geometries. It is based on GEOS (http://geos.refractions.net). Shapely 1.0 is not concerned with data formats or coordinate reference systems. Responsibility for reading and writing data and projecting coordinates is left to other packages like WorldMill and pyproj. For more information, see:
Shapely wiki
Shapely manual
Shapely requires Python 2.4+.
That's a little more to go on, but assumes that you're already a GIS programmer. It's a terrible assumption to be making when you consider how wedded GIS programmers are to not-open source or not-Python platforms and how unlikely they are to be trying Shapely. The real audience is Python programmers coming from outside the GIS business and it doesn't explain to them at all why they'd want to use Shapely. That's something I'm going to remedy, starting with a little blog rambling.
Imagine a situation where you'd like to find or index a substring within another string. Is there "overlap" between the strings, and if so, what is it? Or maybe you'd like to replace certain characters in a string with others. Now imagine that you're compelled to load the text strings into a relational database to perform these operations because such string functions aren't available in any other context. No knock on the RDBMS, a tremendously useful thing, but that's a unacceptable situation.
The premise of Shapely, or one of the premises, is that Python programmers should be able to perform PostGIS type geometry operations outside of an RDBMS. Another is that Python idioms trump GIS (or Java, in this case, since the GEOS library is derived from JTS, a Java project) idioms. Shapely, in a nutshell lets you do PostGIS-y stuff outside the context of a database using idiomatic Python. I've got a ways to go yet in explaining this because I've left you needing to know what PostGIS-y stuff is.
That's the theory, but are spatial operations outside of a RDBMS all that interesting in practice? They are to the GIS community: the OGC's Web Processing Service specification was written to standardize such practice, and I know a bunch of Python programmers that are gonzo for WPS. Myself, I'm -1 on the WPS standard, but +1 on spatially smart web intermediaries. This is one of the possible classes of Shapely applications.
My toy Mush is an example of a pipe-like app that uses Shapely. Feeds go in, feeds come out. Check out this map of intersecting regions around geo-referenced photos in a Flickr feed produced using Shapely. Look, Ma: no database.