Standards? We've got them. Formats: Atom, JSON, GML, and KML. Application protocols: HTTP and AtomPub. AtomPub provides a solid foundation for the next generation of WFS-like geo-CRUD things and is at the core of major projects at Google and Microsoft. I'm not sure why ESRI wouldn't follow suit. Reinventing it is fruitless; extending it behind the OGC's walls of secrecy equally so. Better to get involved with the Atom community and IETF to solve some of the issues that remain open for us geospatial folks: batching, simplification of media (specifically geospatial content) resource creation (maybe with AtomPub Multipart), and filtering.

Paul writes:

No matter how much we (me) might bitch about OGC standards, they have a huge advantage over DIY, in that they provide a source of truth. You want an answer to how that works? Check the standard.

Who is advocating DIY? The Web and the "Cloud" are standardizing on AtomPub. If OGC standards trump one-offs, IETF Web standards trump OGC standards: they are developed by expert internet engineers with years of hard-earned experience in design and implementation of application protocols; they get attention from engineers across the entire Web, rather than just from narrow domains like SDI; they are -- particularly in the Atom/AtomPub case -- discussed and revised in open forums. There are no artificial barriers to participation; if you're a serious, experienced, thoughtful person, you're in. If you want to understand why a standard is the way it is, you can dig in the Atom or AtomPub email list archives for clues, or you can email the list for clarification. Quality and transparency: that's the advantage of these standards.

Shapely 1.0.6 is uploaded, including a Windows installer. We pulled the 1.0.5 installer a while ago because of an irritating problem with the geos.dll we'd been distributing, and are now going to try going with DLLs built using MinGW. Works fine for me with the standard python.org Windows Python 2.5, but I'd appreciate hearing from other Windows users. This release also fixes a bug involved with adapting MultiPolygon GeoJSON data.

My interest in pro cycling bottomed out last summer, but Get Your Grand Tour On has completely revived it. Inspired by David Rees's brilliant Get Your War On -- brace yourself for sarcasm and obscenity.

Speaking of cycling: last weekend I took my vintage 1987 Hardrock on a trail for the first time in 15 years. The 40 pound frame and classic 80's geometry (slightly downsloping top tube) make pulling heavy trailer loads a joy. In the background is the 10th Mountain Division Hut Association's newest hut, just west of Tennessee Pass (3117 meters).

Anything changed since 2007? Yes: REST, the architectural style of the Web, has finally broken through into the "GeoWeb" conference program. The rumored REST track didn't make it, and the agenda remains skewed toward the usual OGC SOA architecture, but 4 out of 66 workshops and papers (of which, to be fair, only about a third cover web services at all) is a nice first step. I assume REST will be a more popular topic at the upcoming ESRI User Conference, but the agenda is so big and the search function too limited to say for sure.

It looks like FOSS4G 2008 has less REST on its agenda than did the 2007 version. That conference website doesn't provide any abstract search at all, so I'd have to scrape it, but only after first obtaining a login. Login to see abstracts ... are you kidding me?

Update (2008-07-09): Josh Livni tipped me that abstracts can now be viewed without login on the FOSS4G conference site, and abstract search seems to have been enabled as well. Using it confirmed my initial impressions: there's no REST on the agenda outside of a geocoding service with a REST API and mention of GeoServer's new REST style administration interface. Other than that, it's back to all W*S, all the time. It looks like the REST session at FOSS4G 2007 was a fluke.

All REST Monday continues. Except for very large values of "inconsistent" -- like "one or the other doesn't use HTTP" -- I think a little more explanation is needed to support this:

REST-based architectures are not inconsistent with the WFS specification.

Again, the five key principles of REST (use of HTTP is implicit), from Stefan Tilkov again, are:

• Give every "thing" an ID

• Link things together

• Use standard methods

• Resources with multiple representations

• Communicate statelessly

The last of these is the only one to which WFS 1.0 strictly adheres. WFS does not specify permanent URIs for individual features; does not specify hypertext links among features, types, and services; uses GET or POST, yes, but interchangeably and in ignorance of PUT and DELETE; and does not specify use of HTTP content negotiation to select data formats. All of Tilkov's REST anti-patterns save number 5 (cookies) are written into the WFS specification, and so it still seems to me that WFS is mostly inconsistent with REST.

I've recommended a couple of Stefan Tilkov's articles before; his new one on REST anti-patterns is equally good. See if you can recognize the anti-patterns most commonly used in geospatial services.

We've renamed our "GeoJSON" package to "geojson", uploaded the first beta release, and plan to finalize it within a couple weeks.

Geojson provides geometry, feature, and collection classes, and supports pickle-style dump and load of objects that provide the lab's Python geo interface. Here's an example of a round-trip through the GeoJSON format:

>>> import geojson
>>> p = geojson.Point([0.0, 0.0])
>>> p
Point(coordinates=[0.0, 0.0])
>>> data = geojson.dumps(p)
>>> data
'{"type": "Point", "coordinates": [0.0, 0.0]}'
>>> q = geojson.loads(data, object_hook=geojson.GeoJSON.to_instance)
>>> q
Point(coordinates=[0.0, 0.0])

The geometry classes interoperate with Shapely via the geo interface:

>>> from shapely.geometry import asShape
>>> x = asShape(p)
>>> x.wkt
'POINT (0.0000000000000000 0.0000000000000000)'

A manual is forthcoming; for now there are many doctest examples. We would appreciate your giving it a try, which is as easy as:

$ easy_install geojson

We had our first favas this evening, sautéed with garlic in olive oil. Pink Côtes de Provence, not Chianti, and ravioli, not liver. These were young enough that we didn't bother to peel the individual beans after shelling; the skins have a slightly bitter, artichoke quality that complements the intensely sweet pea interior (if you like hoppy beer, you'll like favas). Our toddler found them tolerable enough, though she by far prefers the snow peas that are also just starting to arrive -- raw, never ever cooked, and best straight off the vine. It's great to have peas and beans now as we were getting a bit burned out on spinach and turnips.

Andy Powell's presentation on Web 2.0 and repositories is just as relevant a read for GIS designers as it is for archivists. These communities have much in common, including:

• A mission to archive and curate comprehensive, unique datasets.

• Information architectures, formats, and protocols that pre-date the Web.

• Entrenched agendas that overshadow architectural concerns.

In the institutional repository space, open access voices don't want their agenda derailed by debate about the re-architecture of the systems to be opened. Likewise in the open source GIS, or FOSS4G, space: businesses that are barely succeeding in winning government and industry clients over to open source solutions based on "OpenGIS" standards aren't keen on having these standards undermined for any reason.

Powell's assessment is that the way forward for repositories is either simpler (Atom, for example) or more complex (RDF, which I'm told is to the OGC what the XML mapfile is to the MapServer community) than the current approach. Or both. I think this is true for geospatial as well.

Congratulations, everyone. From the official announcement:

The GeoJSON Authors are proud to announce the finalization of the GeoJSON 1.0 Specification.

Representing more than a year's worth of community discussion and development, the GeoJSON specification describes an easy to use, extensible format for transferring geographic data over the web. With support in more than 20 different applications, GeoJSON is already quickly becoming a de facto standard for transferring geographic data in a JSON format. The finalization of the spec represents the final step in formalizing the GeoJSON format for encoding this data.

More information on GeoJSON can be found at http://geojson.org/, or from the GeoJSON mailing list at http://lists.geojson.org/listinfo.cgi/geojson-geojson.org.

More from Martin and Christopher.