Version 1.0.7 fixes problems with polygon ring dimensions and reference cycles. Related: I fixed the only known Rtree bug and am lobbying hard to push it ahead to 1.0.

This is better, as I was saying. It's nice to see Python catching on in my home state's GIS department, and also to see ESRI users catching on to the power of more idiomatic Python. It's more than just an open source Avenue, after all.

Speaking of better Python things, yesterday I found out about Tarek Ziade's Atomisator project. It's the kind of framework for feed processing that is entirely lacking in my Mush application. A comment on his entry then led me to TOPP's Melkjug, which has a slick web UI for creating feed filters that is also not to be had from Mush. I think I'll borrow liberally from each, and maybe Mush can provide some geographic processing and filtering inspiration in return.

Mateusz's post about marshaling geometries from hex-encoded WKB strings in C++ reminds me how easy this is in Python using built-in string methods and Shapely:

>>> from shapely.wkb import loads
>>> g = loads('01010000005839B4C876BEF33F83C0CAA145B61640'.decode('hex'))
>>> g.wkt
'POINT (1.2340000000000000 5.6779999999999999)'

My only regret about switching to dynamic languages for (almost) all my development is that I didn't go straight to Python. Last weekend I ran into a former co-worker at the Fort Collins downtown street festival and was reminded about the enormous Perl legacy I left behind at that shop.

Speaking of maps in the media -- I like this one of John McCain's homes:

I know he doesn't personally use the internet tubes, but maybe an aide can print it out and help McCain keep track of these places.

Does this kind of "attack map" contribute to the stupefication of US politics? Yes, perhaps, but I for one am happy to see the other side get the rare pleasure of defending itself from this kind of bullshit. For once.

The GeoJSON working group didn't target specification of an API, but I always imagined we'd be using something like this.

TurboGears will join the ranks of geospatially-enabled Python frameworks with the addition of tg.ext.geo to tgtools. From Sanjiv Singh's Summer of Code status email:

4) TG2 Geo Extension with MapFish[6] The tg.ext.geo extension implements the server side component for vector query and editing. It is mainly based on MapFish server. However the templates are modified to suit the TG Object Distach BaseController. This may change in future and be fully based on MapFish server which uses a RESTFul controller. The extension makes use of existing PythonGIS tools like Shapely and GeoJSON. Thanks to Eric Lemonie, Sean Gillies, Matt Russell and the GISPython community for bringing the GIS tools to python developers. A demo application with openlayers based feature selection and a DojoGrid for displaying the attribute data can be seen at http://sanjiv.homelinux.net/. Thanks to Michele Bertoldi for helping me with his Dojo Grid.

I love seeing Shapely and Geojson put to use (MapFish, by the way, is a Shapely-using Pylons application). Sanjiv's application discovered a bug in Shapely and helped improve the software for everyone. I note that his mentor was Chris Perkins, a Python programmer and Plone developer at the National Renewable Energies Laboratory in Golden, who I would probably have met already if I'd been going to the Pythoneers meetings in Boulder. I need to get back to them soon.

If there's anything the GIS mainstream knows about REST, it's that REST is simpler and more lightweight than SOAP, "Web Services", or the OGC's service architecture. This notion is erroneous, and it's irresponsible to propagate it.

Bill de hÓra makes the distinction between disciplined and simple:

REST is not that simple; you can fit the basics into a few slides, but its purpose is to induce simplicity into the right places, not [to] be simple.

He's also compiled a great list of XMPP links.

Good writing, great analogies -- if anybody can rescue the concept of geospatial cloud computing from the pundits, Kirk Kuykendall can:

Look at what happened to engines. A hundred years ago they were the hot new technology - both internal combustion as well as electric. In those days you had to be intimately familiar with the physics of combustion to operate a motor vehicle. Now I rarely open the hood of my car. So in a sense engines have disappeared, but really they were subsumed by the automobile. What remains is a higher level object - the car - with only a few terms (like ignition) here and there hinting at what lay underneath.

From the post Kirk references:

GIS has been waiting for the cloud. GIS was born to exist in the cloud. It will reach its highest potential there. The Cloud is fertile ground for a GIS. A GIS is about much more than location alone. Its truest value and highest potential are exposed through the capability to perform spatial analysis, model and simulate. In a sense GIS is a 5-speed F1 racer that has been operating in second gear. The cloud has enormous potential to change that, shifting spatial gears and accelerating the wider use of GIS functionality. Buckle up - the ride is about to begin.

Shorter Jeff Thurston: I am as high as a kite.

When I write about Python I'm almost always writing about "C Python", the Python interpreter and extension modules written in C and executed in the C runtime environment. The first alternative was "Java Python" or Jython, which is written in Java and executes in a JVM. It's author, Jim Hugunin, switched to working on IronPython (.NET), and it stalled for a while before reemerging last year under the sponsorship of Sun. The Jython team has been using Django, one of Python's highest profile applications, as a development target and have reached a major milestone.

I don't know enough about Java web app deployment to comment on the usefulness of this (Using Tomcat to run Django when you could just run it under mod_wsgi?) other than to get more direct access to Java libraries like Lucene, but it certainly inspires confidence in Jython. I could see Shapely or GeoDjango adapted to Jython to bring some geoprocessing power to the framework. Each are currently based on GEOS, which is acknowledged to suffer in translation from Java to C++. Jython versions based instead on JTS would have more features and better performance.

Via Sean McGrath.

Sounds like FOSS4G 2008 is going to have an even stronger proprietary flavor than the 2007 edition. Says Gavin Fleming:

FOSS4G 2008 is not just about open source – the whole SA GIS community will be there, including all the normal 'proprietary' GIS community. Content, exhibitors, sponsors (including GIMS) are from the open source AND the proprietary communities, not that there is a clear distinction, with many being from both. If you attended AfricaGIS in '05, or any GISSA or local GIS conference for that matter, FOSS4G is for you and is going to be bigger and better. It is indeed also the ‘GISSA 2008’ conference. Learn about how proprietary and FOSS GIS can work together. Or, learn about how to make the transition from proprietary to FOSS.

I think this is not a positive trend.