My boss, Tom Elliot, is an expert epigrapher as well as a fine programmer and geo hacker, and has a new blog on these subjects: Horothesia. Or, as we say around here: τὰ ὁροθέσια. In a way, epigraphs are the push-pins and popup description bubbles of ancient geography.

After talking with Chris and seeing Camptocamp's plans for using JSON between the client and server sides of Cartoweb 4, I am going to get with the GeoJSON draft again. To help out, I have updated GeoJSON, tagged it as 1.0a1, and uploaded it to the Python Package Index: http://pypi.python.org/pypi/GeoJSON. It complements Shapely like this:

>>> from shapely.geometry import Point
>>> point = Point(0.0, 0.0)
>>> import geojson
>>> geojson.dumps(point)
'{"type": "Point", "coordinates": [0.0, 0.0]}'

My favorite hobby horse was apparently given an inside track by the conference session committee: Charlie, Chris, and I got to speak in succession and tag team on REST. I started by trying to remind people how important the Web is, and how practical it would be to follow its best practices when designing geospatial services (instead of going with WS-*). Chris then used FeatureServer to demonstrate how easy it is to work using nothing but good old HTTP. Charlie introduced the Atom Publishing Protocol, a standard for manipulating collections of resources that is better suited than WFS-T for the Web. I don't know if anybody sat through all three of these talks (and kept their sanity), but we did get some good momentum going. And without any of the "REST for the mass market" nonsense that sometimes crops up in some quarters.

I missed Harris Kutagic's talk, but heard that he'd demonstrated parcel data editing in an OpenLayers/MapGuide application using just HTTP PUT instead of WFS-T. I've foreseen exactly this type of application for REST. A city's parcel information system is more like the ancient places of my Pleiades project than almost anything else in the GIS business and the usefulness of URLs for every parcel is obvious. Ownership (at least) of parcels changes independently of other parcels, and this also lends itself to use of PUT.

Several other presentations mentioned REST in passing and, like I said before, even the hardcore OGC service implementers are showing a lot of interest in and knowledge about REST. GeoRSS is already a very big deal in the geospatial business. Once people really catch up with how GData and Atompub standardize creation and modification of entries within feeds, the nature of new services is going to start changing quickly.

At the end of his talk, Charlie invited people to join our Geo-Web-REST discussion group. We're approaching 100 members, and have representatives from many of the most important open source projects, neogeography startups, vendors, search engines, and standards committees. Together, we're starting to sound out the best practices for GIS and REST.

I'm very glad I attended Bastian Schaeffer's presentation about the 52N WPS. They are doing almost everything exactly right: a DSL for defining processes (BPEL in their case), user-defined and uploaded processes (what they call transactional WPS), and they seem to get what would be the RESTful way to do this stuff (I need to resume the discussion we were having about asychronous processing and callbacks). But it's still WPS, and not really for the web.

I got a glow-in-the-dark Ultrastar (Discraft's ultimate disc) with a TOPP hot-stamp from Chris Holmes. Reminds me how much I miss ultimate tournaments.

Alexander Quinn demonstrated a Library of Congress mapping application based on OpenLayers, MapServer, and Django (there's more Python here than in previous years) with smartly designed popups and labeling hacks.

Jan Hartmann is teaching ~~Belgian~~ Dutch villagers how to georeference historical maps and help tell the story of the invasions and occupations of his hometown since the 17th century.

Aimee Stewart is doing ecological niche modeling on the web with Python (yet again) and RESTful web services instead of SOAP.

Camptocamp is switching from PHP and mapscript to a javascript framework based on OpenLayers and Dojo for CartoWeb 4. Pierre Giraud's demo used services implemented with Pylons (yet more Python). I must find out how well CartoWeb 4 fits into Zope page templates. Shapely has had a bunch of contributions from his colleague Frédéric Junod.

The conference wifi melted down this morning, but the event is otherwise running well.

I've put myself on the hook to explain a few different things outside of my scheduled presentation (3pm Tuesday, Saanich Room, after the GeoDjango talk): how to sanely manage map service auth and customization, how to do data processing using HTTP/1.1 only (no WPS). Maybe you want you ask me to pitch your product on my blog (I won't), or ask me to pour you some REST kool-aid (I will), or throw rotten vegetables (which I will nimbly dodge). It's the biggest open source (and special proprietary guests) GIS conference ever (take a bow, Paul Ramsey). I have no booth and my physical appearance is modal (sedentary white male). How then are you going to find me? Shouldn't be too hard; i'm a Free Software Zealot, and you can borrow the special glasses from almost any OSGeo member that will reveal my true form.

Speaking of Cyrene, on page 3 of the Times International section is an article about Saif al-Islam el-Qaddafi, a Ph.D. student at the London School of Economics, and the son of Libya's president. A photograph of Mr. Qaddafi speaking from the Greek ruins of Cyrene accompanies the story. He's speaking about tourism, but there is clearly a wider, symbolic, appeal being made to the West.

I'm in Seattle for the pre-FOSS4G weekend, hanging out with family and doing big city stuff: going to the zoo, art museum, and Tom Douglas's dining empire. The flight went really well, and I'd be remiss if I didn't share the secret to traveling happily with a toddler. Always carry at least one big book of stickers for every 2 hours of time on board. Even if you don't have a toddler of your own; you might be able to pass the book to the harried parent in the next row and buy yourself a couple hours of peace. I recommend pirate stickers -- it's never to early for a child to learn how to wield a cutlass and say "Arr!"

My issues with the specification coming together at http://geojson.org are orthogonal to Matt Giger's. Lists are the closest thing in JSON to tuples, and are the right way to represent points within lines and rings. The semantics of GeoJSON's:

[ [x1, y1, z1], ..., [xn, yn, zn] ]

are pretty obvious and the structure doesn't have to be unpacked like Matt's:

[ x1, y1, z1, ..., xn, yn, zn ]

Should you represent geometries as lists of lists in your analysis or visualization software? Probably not, for the reasons that Matt mentions: memory overhead and speed of access. But we're just talking about the wire format here, and representational clarity trumps computational efficiency on the Web. Limitations or quirks of our implementations shouldn't be engraved into our standards.

Which brings me to my issues with GeoJSON: the proposed mandatory "type" member for all objects. The argument for "type" is that it helps clients distinguish between geometries, features, and collections when parsing data structures. I think this is an entirely optional and avoidable implementation quirk that should not be a mandatory part of the specification.

Best practices for geospatial use of JSON make the need for "type" vanish. Querying a collection resource (all features from "cities" within a bounding box, for example) should return nothing but GeoJSON feature collections. This JSON structure in turn contains nothing but features. A request for the GeoJSON representation of a single feature resource should return nothing but a GeoJSON feature. It's as simple as that: return nothing but the proper JSON data structure.

Same story for data posted or put to resources. Collection resources should expect nothing but GeoJSON feature collections in a POST body. Single feature resources should expect nothing but GeoJSON features in a PUT body. The "type" member is completely needless, and in fact might conflict with the information that is ultimately most important: the class of web resource you're manipulating (collection or member) and the HTTP method you're using to manipulate it.

We in the geospatial business really do suffer from "standard euphoria", and need to remember there's only one first chance to get a standard right.

Update: more from Matt.

Now, thar be first-class privateerin'. Cap'n Perry dug up the secret of doublin' ye firepower. Matey, if ye not be comin' to Victoria, send me the address of ye home port, and I be rowin' o'er to the Mothership tonight to fetch ye booty.

I think I'm going to offer a bounty for the first open source GIS software that does something cool using pp [more about Parallel Python]. New Belgium swag, maybe? Drinks on me in Victoria?

Building and installing the GDAL/OGR Python bindings can be a bit of a pain in the neck. It's complex software with a lot of associated data. At the Lab, we're using zc.buildout (see pcl.buildout for a specific example) to create replicable, version-controlled Python environments that include GDAL/OGR (as well as MapServer and PostgreSQL + PostGIS).

Another new option for deploying intricate environments is Ian Bicking's virtualenv. From the readme:

virtualenv is a tool to create isolated Python environments.

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).

Virtualenv covers the same ground as the GDAL project's FWTools, but is more programmable and customizable. It integrates with setuptools, and so getting a fresh Python GIS environment from the package index could be just as easy as:

$ sudo easy_install gdal-env

Of course, someone would have to actually create and upload that gdal-env package. Bicking advises us to switch from workingenv to virtualenv.

I've written to the geo-web-rest group about CouchDB, a distributed, non-relational database, and now Sam Ruby has a Python prototype. Basura uses some elements that I like to blog about: namely JSON and WSGI.