Hey, sometimes you can't avoid the OGC's service architecture. OWSLib makes W*S suck less (apologies to Bob Ippolito) while you and I find our way back to the Web from the land of SDI. OWSLib 0.3 adds preliminary support for coverage services, contributed by Dominic Lowe of the British Atmospheric Data Centre, a colleague of Bryan Lawrence.

I'm a big fan of the Debian GIS Project and pleased to see that Shapely is getting some of its attention. Meanwhile, I'm still building GEOS 3.0 from source (with Kai's hexagonit.recipe.cmmi) because Hardy is still at GEOS 2.2.3.

I just want to point out how well Schuyler Erle's implementation of Douglas-Peucker line simplification plays with Shapely.

>>> from shapely.geometry import Point
>>> point = Point(0.0, 0.0)
>>> outline = point.buffer(2.0, quadsegs=32).boundary
>>> coords = list(outline.coords)
>>> from dp import simplify_points
>>> simple_coords = simplify_points(coords, 0.25)
>>> from shapely.geometry import LineString
>>> simple_outline = LineString(simple_coords)
>>> outline.length
12.565109003731115
>>> simple_outline.length
12.245869835682875

The simplify_points function requires a sequence of coordinate tuples. The coords property of a Shapely geometry is an iterator over coordinate tuples, but you can make a sequence from the iterator by using Python's built in list function.

>>> from numpy import asarray
>>> from matplotlib import pylab
>>> a = asarray(outline)
>>> fig = pylab.figure(1, figsize=(5,5), dpi=72)
>>> pylab.show()
>>> pylab.plot(a[:,0], a[:,1])
[<matplotlib.lines.Line2D instance at 0x8ae7d8c>]
>>> b = asarray(simple_outline)
>>> pylab.plot(b[:,0], b[:,1])
[<matplotlib.lines.Line2D instance at 0x90bc86c>]

The original:

And simplified:

The Programming Historian looks great to me. It covers HTML parsing (with Beautiful Soup), regular expressions, Unicode, and link traversing, with more to come.

Via the author, Bill Turkel.

One bug fix and a simple GEOS geometry cache to improve performance when wrapping coordinate data stored outside of Shapely. http://pypi.python.org/pypi/Shapely/1.0.4.

In comments on a post about Javascript geometries, Paul Ramsey and Martin Davis wondered about a pure Python version of JTS. It might be an interesting project, and maybe you could coax reasonable performance out of it with psyco or Cython, but it wouldn't perform as well as something based on C (for C Python) or Java (for Jython) or C# (for IronPython). Consider Ian Bicking's HTML parsing benchmarks: lxml, based on libxml2, is far faster than anything else. The need to calculate spatial operations in C rather than Python is greater yet.

If Google would provide some basic spatial indexing (for App Engine), you could try to go the rest of the distance with the help of an external web geoprocessing service. You might not need a PyTS after all.

Keytree (also known as pleiades.keytree in our repository) is a simple package of ElementTree helpers for parsing KML. I needed it, didn't see anything else like it out there, and put in a little extra work to make it more generally useful. If you're already using ElementTree and are curious, give it a try. It plays well with Shapely, of course:

>>> from xml.etree import ElementTree
>>> tree = ElementTree.parse(open('archaic.kml', 'rb'))
>>> kmlns = tree.getroot().tag.split('}')[0][1:]
>>> placemarks = tree.findall('*/{%s}Placemark' % kmlns)
>>> p0 = placemarks[0]
>>> import keytree
>>> f = keytree.feature(p0)
>>> from shapely.geometry import asShape
>>> shape = asShape(f.geometry)
>>> shape.wkt
'POINT (21.9725000000000001 32.8962999999999965)'

Keytree parses out points, line strings, and polygons, but not yet geometry collections. I'll make a real release of it after I get a chance to work on compatibility with lxml.

I think it would be neat to see QGIS community plugins done Trac-style, as eggs.

Wouldn't you know: Dick Cheney and his shadow scientific community have other plans for those Right Whales.

Most cynical. Government. Ever.

Howard and Marios have released SpatialIndex 1.3.1. This fixes a few memory leaks and gets us a couple steps closer to being ready for production on Windows. From the release notes:

• Fixed gcc/vc compatibility issues with TemporaryFile.cc
• Fixed memory leaks in LineSegment.cc
• Fixed memory leaks in MovingRegion.cc
• Fixed memory leaks in mvrtree/Node.cc
• Renamed rand48.hpp to rand48.h

Aha!

Several FRII accounts have been compromised over the past few weeks due to a spoof email sent out to obtain their login info. These compromised accounts, unfortunately, led to the FRII ip being blacklisted on several ISP's. We our hopefully on the tail end of the matter but it sounds like Akismet might be an additional ISP we need to contact. If you haven't attempted to send a message to an Akismet user today, go ahead and attempt to again. If you get a bounce back, please forward the message to customercare@frii.com for our evaluation.

I got confirmation yesterday that Akismet was indeed sending my comments to WordPress blog spam bins. I think this is the first time I've ever been blacklisted.

And now I just received the spoof email:

Dear Frii Email Account Owner,

This message is from Frii messaging center to all Frii email account owners.

We are currently upgrading our data base and e-mail account center.

We are deleting all unused Frii email account to create morespace for new accounts.

To prevent your account from closing you will have to update it below sothat we will know that it's a present used account.

CONFIRM YOUR EMAIL IDENTITY BELOW Email Username : ......... ..... EMAIL Password :................

Warning!!! Account owner that refuses to update his or her account within Seven days of receiving this warning will lose his or her account permanently.

Thank you for using Frii!

I can't believe people still fall for this con.

Here, continuing on from my previous post, are some of the forces arrayed against an all-encompassing OSGeo Python framework:

Scarcity: few develop GIS applications using Python, fewer applications that would benefit from a global library, and fewer yet would contribute to the development of the global library. From my experience, you can't expect more than 3 people at the top of this community pyramid. That's probably not enough. And you can't really count on this number increasing very much in the future. Users want apps and data, not libraries and APIs. See Google Earth. Yes, there are exceptions, but Java, not Python, is their home.

Scale: GDAL, OGR, PROJ4, GRASS, QGIS, MapServer, ... data, analysis, projections, stats, graphical user interfaces, printed and plotted maps, service oriented architecture, ... that's a lot to keep in your head. Designing such a thing is a big job for a small team, not something you knock out in a week unless you join the GeoTools/GeoAPI cargo cult like I did when I started PCL (after which you'll realize that Python programmers don't want GeoTools). Programming in Python is more productive than programming in Java, or .NET, but designing Python libraries isn't any easier. Without a driving business need or lots of itch scratching (which won't happen, as I explained above), the task of designing a global OSGeo Python library is doomed by the size of its scope.

Physics: a Python library that depends on

• GDAL/OGR (and Xerces, etc)
• MapServer (and Agg, etc)
• GRASS
• QGIS (and Qt, etc)

is like a giant cinema spider, awesome on the drawing board, but in reality something that can't but collapse under its own weight. There are too many dependencies, too many of which have no current binaries, with incompatible Python bindings written by hand, or generated by SWIG or SIP. There's also a rather large amount of functional overlap among these projects, governance of which is something that GeoTools (which I'm continuing to hold up as a successful holistic library) doesn't have to be concerned about. I suspect the social and software engineering details haven't fully dawned on OSGeo developers yet. These details are not an itch I need to scratch, they are a patch of poison oak I need to avoid falling into.

Well, that's the verbose edition. The shorter history of PCL: it's brutally hard and there is precious little reward for the designer. I feel like there's more to write on Python and geospatial or GIS frameworks, especially with reference to the Python web framework debates, but that's for another day.