It's "AtomPub", not "Atompub" as I've been writing:

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations.

The slides that I will be using at the National Endowment for the Humanities/Consiglio Nazionale delle Ricerche "Using New Technologies to Explore Cultural Heritage" conference are online.

Speaking of slides, my FOSS4G slides are rather useless on their own. I'm going to try to herd my notes up into a paper over the next couple of weeks.

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.

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.