Tantek Çelik's call for standards that are as open as possible appeals to me.

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 benchmark.py
WorldMill (Cython)
8951.09 usec/pass

ogr.py (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.

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 bootstrap.py
$ ./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:

...
[gdawgpy]
recipe = zc.recipe.egg
interpreter = gdawgpy
eggs =
    GDAL
    WorldMill
    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.

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.

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.

Many are new to me: http://ancientworldbloggers.blogspot.com/. Via Horothesia.

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.

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.