Please consider giving your users the power to POST and PUT KML from Google Earth to arbitrary URLs other than http://bbs.keyhole.com. Anything you can do about this, Ed?

First, Sam Ruby on GeoRSS, and now Stefan Tilkov on REST and CRUD: lessons from the Web for we who would build the Geo-Web. Listen up.

It's interesting, too, that Assaf Arkin uses OASIS as an example of an entity trying to become cool by association with REST, as the OGC and others plan to put ebRIM at the center of geospatial catalog services.

Keyur, you must think in terms of resources, not object methods. Nouns, not verbs. In a restful architecture you don't cause your person to talk, you listen to the person's words:

GET /persons/1

or, if you want to be fancy:

GET /persons/1/words

Likewise, you don't cause them to walk a step, you update the person with a new location:

PUT /persons/1
{ ..., "location": [[-100.0, 40.0]] }

or:

PUT /persons/1/location
{ "location": [[-100.0, 40.0]] }

Matrix URIs? They're standard with Rails, but mainly to allow PUT operations to tunnel via POST from dumb clients like the browser:

POST /persons/1;edit
{ ..., "location": [[-100.0, 40.0]] }

Front Range Pythoneers: OLPC (!) and testing, 18 April.

FRUGOS: MapServer and OpenLayers class at CU-Denver, 25 April.

At All Points Blog. The mainstream hasn't yet discovered that the community has been earnestly discussing REST since last fall.

Raj, Paul, Tom: don't neglect to write soon about the process of approving the GeoDRM Reference Model, and how it's going to usher in a brand new era of data sharing. Congratulations! The masses will cheer you and throw flowers, I'm sure.

Related: yesterday, a reader pointed me to an article in Government Computer News about what I'll call GeoCYA, in which the OGC CTO walks a fine line between removing, and stoking, "the fear of litigation".

I'm surprised nobody noticed the potentially exploitable feature collections responses in my initial Hammock deployment. Best practice is to return JSON objects rather than arrays. Bob Ippolito explains all about it here.

The difference between Microsoft's and Google's urban web maps says a lot about the mindset of these companies:

Microsoft -- photorealism.

Google -- hyperrealism.

Good news for Python geo-programmers: Howard Butler has kicked out the jams, unstuck my Python/C++ R-Tree experiment, and allowed me to release Rtree 0.1.0. This package is based on Marios Hadjieleftheriou's spatialindex, and now allows you to persist a tree on disk. The one known bug is that it's a no go on 64-bit architectures. This will be addressed in the 0.2.0 release by using spatialindex 1.1.1.

In other news, I moved Rtree and Quadtree from Pleiades to the GIS-Python repository. Thanks to svndumpfilter, it was almost too easy.

Here's the code for the toy not-a-WFS I wrote about yesterday [browse]:

$ svn co http://icon.stoa.org/svn/pleiades/hammock/trunk hammock

Requires GeoJSON:

$ svn co http://svn.gispython.org/gispy/GeoJSON/trunk GeoJSON
$ chdir GeoJSON
$ python setup.py install

in addition to simplejson (needed by GeoJSON), elementtree, selector, and wsgiref (use setuptool's easy install script, or build from Cheeseshop tarballs).