GDAL and GEOS Releases

GDAL 1.5.0 and GEOS 3.0.0 were released during the holiday and are now used in the Knowhere and Gdawg buildouts. The big change in GDAL is new Python bindings. The ones that Howard Butler has been calling the next generation bindings are now the official primary Python bindings. My benchmarks say 1.5.0 is a little (~5%) slower than 1.4.2:

sean@lenny:~/Projects/Gdawg$ ./bin/gdawgpy
WorldMill (Cython)
8951.09 usec/pass (new bindings)
24846.93 usec/pass

WorldMill remains faster at its tasks. The GDAL/OGR C API hasn't changed in 1.5.0, so WorldMill builds without a hitch.

Replicable Python Geoprocessing Environments

I've finally followed through on earlier hand waving about combining GDAL with zc.buildout to make replicable Python geoprocessing environments. Grab the Gdawg tarball: Gdawg.tar.gz, extract, and cd into its root. Then build it out like so:

$ python
$ ./bin/buildout

When done, you'll have a custom Python interpreter with GDAL and (for fun) WorldMill:

sean@lenny:/tmp/Gdawg$ ./bin/gdawgpy

>>> from osgeo import ogr
>>> import mill

Add any other Python eggs you need by customizing the list of eggs in the gdawgpy section of buildout.cfg:

recipe = zc.recipe.egg
interpreter = gdawgpy
eggs =
    simplejson # etc

All the familiar GDAL/OGR utility programs are found under parts/libgdal/bin.

What do I mean by replicable? You can control versions of every piece of software in this buildout and even put the config file itself under revision control. It's like an FWTools where you control the versions of everything.


Re: Replicable Python Geoprocessing Environments

Author: Christopher Schmidt

Does it work on Windows?

Re: Replicable Python Geoprocessing Environments

Author: Sean

It might, but not without MinGW or hard work. I'm trying to show people another build tool, not trying to sell a replacement for the FWTools Windows binaries.

Britannia Superior Preview

Also known as Barrington Atlas Map 8. Just got this data back the other day. Roads, settlements, mines -- you can just pick out a few copper mines in what we now call Wales. We'll be rolling it out into the Pleiades site in the new year.


I miss Seattle already. Normal posting from good old Fort Cowpie will resume shortly.


I don't understand how you'd expect a different approach from Microsoft. Being a late entry, the company could benefit from shaking things up a bit.

Update: Or not.

Last REST Post of 2007

Here's the take-away from the past year's discussion about REST and geospatial. My own take, that is. There are differences of opinion among the participants of the Geo-Web-REST group.

REST is an architectural style, not an API. When you hear or read "... REST API ...", that's a smell, a signal that something might not be quite right inside.

REST is the architectural style of the World Wide Web. "Web API" is a more meaningful term, although not all Web APIs are RESTful. Some are GETSful.

The OGC service architecture is not RESTful. The style of the OGC architecture is non-RESTful CGI/RPC. Feature, map, and coverage resources are kept hidden behind service endpoints. We're still partying like it's 1999.

GML is compatible with REST, but XML Schema is still a wretched beast and there are no XLink-traversing GeoWeb browsers of note.

Look to Google Earth and KML for REST inspiration. It's about the links. Also look to Google's AtomPub-ish APIs for YouTube, Picasa, and OpenSocial. There's no transactional WFS involved there, and that's something to think about. Google chose AtomPub for wider interoperability.

REST is not a silver bullet. Distributed applications are hard.

These are the tenets of REST:

  • Give every “thing” an ID

  • Link things together

  • Use standard methods

  • Resources with multiple representations

  • Communicate statelessly

Do read and recommend Stefan Tilkov's Brief Introduction to REST, from which the tenets above are taken. It's excellent.

Disregard the Emerging Technology: Geospatial Web Services and REST article in Directions. I don't care who linked you to it; they probably didn't read it very closely. This sounds mean, but that article will make you dumber about REST.


Re: Last REST Post of 2007

Author: Norman Barker

Sean, I have just read this and it makes some good arguments - perhaps SOAP can play after all, and the OGC have ebRIM :-) I have been enjoying the discussion of REST on this blog - thanks!

Re: Last REST Post of 2007

Author: Allan Doyle

Ganesh talks a good game. But remember that HTTP is itself a dumb-network/smart endpoint protocol that rides on top of TCP (and thus can also make use of IPsec). SOAP tends to ride on top of HTTP, and is generally run at a higher level on the networking stack than HTTP. True, SOAP can run on SMTP, or any other protocol, but as implemented it's on HTTP probably 99+% of the time. Ergo, there is no protocol advantage. The entire smackdown is moot.

Re: Last REST Post of 2007

Author: Allan Doyle

And, just one more thing... it strikes me that if you were to apply REST principles to SOAP you might just come up with something approaching "SOAP message with WS-Addressing headers". In other words, REST is a set of architectural constraints that can be embodied on any distributed system that has the ability to provide unique IDs for resources which can themselves contain links to other resources.

Re: Last REST Post of 2007

Author: Keyur

Last REST post? 13 days is a lifetime.

Knowhere Project Wiki

I made a new wiki page for Knowhere. It's my Christmas present to everyone. What, you were expecting something other than open source software?

The buildout failed on my PowerPC iBook, which has gcc 4.0.0. Howard Butler has been successfully building the spatialindex library on his servers with gcc 4.0.1, so it may build on newer OS X systems as long as you have Python 2.4.

RESTful Marketecture

That's a great term. Bill de hÓra:

Ascribing REST to the SimpleDb API might be down to lack of knowledge or marketecture; hopefully they'll get the API* sorted out soon, before it gets used heavily.

The GIS industry leader is soon to release new REST stuff. We'll see whether it abuses the architectural style like Amazon does or if it's the real deal.

Update (2007-12-17): from Assaf Arkin:

1999 called, they want their CGI scripts back.

That's more or less how I feel about the OGC WxS service architecture.


Re: RESTful Marketecture

Author: James Fee

I think many folks have great hope that Amazon actually nails this SimpleDB. It will be interesting to see if hey can.

Re: RESTful Marketecture

Author: Paul Ramsey

I hope so, but the problem just got a lot harder for them. In addition to delivering a better technological solution, now they also have to surmount the psychological hurdle of admitting they got it wrong the first time. That's a high bar for most organizations to clear.

Re: RESTful Marketecture

Author: James Fee

How about this Sean? A RESTful version of Amazon's SimpleDB

Re: RESTful Marketecture

Author: Sean

Yep, I saw that one. Assaf Arkin did something similar, with code. People are mystified that Amazon could get this wrong after they got S3 right.