Yes, I got suckered back into watching the TdF this year, even though I figured it was pretty likely to have another meltdown. Least credible: le Tour or Alberto Gonzalez? It's a toss-up.

Christopher Schmidt and Howard Butler have teamed up to create http://spatialreference.org/, a home on the Web for user-generated spatial and coordinate reference systems.

It's final. Tim Bray writes:

There's one thing of which I'm confident though: if Atompub takes off, it'll be in at least one area that makes no sense at all to me, seems completely crazy.

One of those areas where the Atom Publishing Protocol takes off just might be geospatial.

All Points Blog. David Siedband and Sally Kleinfeldt are working on implementing the interfaces of Plone Maps and zgeo.geographer for GPS-tagged digital photos uploaded to Plone, making it easy to make a Google Map or provide GeoRSS feeds of photo locations.

Update: release candidate is available now.

The promise of WSGI is that Python web applications can be made more interchangeable. By implementing one simple interface, your application can be run with Django, TurboGears, or one of many other frameworks.

I'm developing Mush using wsgiref, a very basic WSGI server included in Python 2.5's standard library. For testing this is fine, but I need something something more full-featured for the live service. I tried a few options and then settled on deploying Mush with mod_wsgi.

Like mod_python, mod_wsgi embeds Python interpreters in Apache processes. The advantage over mod_python is that a WSGI application can be trivially configured. To serve my Mush application, mush.urls, all that is needed is one script:

# mush.wsgi

# import URL dispatching WSGI app
from mush import urls

# mod_wsgi looks for the name "application"
application = urls

and one new Apache directive:

WSGIScriptAlias /mush /path/to/scripts/mush.wsgi

Easy. According to the author, mod_wsgi is feature complete and a 1.0 release candidate is coming soon.

I think community generation of data is a good thing, but community in and of itself isn't enough. I'm going to go out on a limb here and predict that, soon, any "community" enterprise that is not also a rewarding, multi-dimensional game will struggle. OpenStreetMap (for example) succeeds because it's full of good games: community building, sticking it to The Man, and winning respect in the industry are just the obvious ones. Are there any games worth playing at TeleAtlas? That's the crux.

Interesting. Just 3 months ago, I wrote:

Eventually, WxS will be used almost solely for interoperation with legacy GIS applications.

That eventual day might have just taken a little hop forward.

I'm throwing a party this weekend featuring my most ambitious ever grill-roasting enterprise: whole leg of pig with citrus marinade and sauce. Last weekend we made a practice run with a beef rib roast -- you must try this if you eat beef -- and it came out perfectly. The pig itself was raised naturally and locally, on a farm not a factory, and is mighty tasty. It's leg has been marinating since yesterday in a bath of peppery, sugary, zesty lime-orange juice. I'll spare my vegetarian readers the pictures.

I almost wrecked this party before it began. My wife asked how long it would take to cook. I said that it would be about 30 minutes per pound, or roughly 5 hours. She insisted on weighing the leg using a scale (I'd simply hoisted it and guessed), and we discovered that I'd underestimated it's mass: 15 pounds was going to require more like 7.5 hours!

What to drink with it? Something pink, of course.

The growing consensus is that map image and feature services can be (and should be) done RESTfully. Is there any aspect of web GIS that cannot? Geo-processing, perhaps?

Last week I started to roughly sketch out how one might RESTify an OGC Web Processing Service (WPS). Post data to a process resource, get back a 202 ("Accepted") response with a "job" URL to be checked for status ... more or less what Richardson and Ruby propose in Chapter 8 of "RESTful Web Services". Then I remembered that there is a different approach, at least for data that is already on The Web: pull your data through a processing resource with HTTP GET. Like Yahoo Pipes.

I've got a feed at http://pleiades.stoa.org/places/settlement/classical.atom. It contains the locations of human settlements in ancient Lycia and Pisidia attested to be occupied during the Classical period, and I want to find the intersections of their spheres of influence. For that matter, I'd like anyone to be able to find those intersections, using whatever radius they wish. Furthermore, I'd like to let people process practically any GeoRSS feed in this way.

To this end, I've made a process resource at http://sgillies.net/mush/self-intersection. You pull another feed through it via a URL like:

http://sgillies.net/mush/self-intersection/
?url=http%3A%2F%2Fpleiades.stoa.org%2Fplaces%2Fsettlement%2Fclassical.atom&d=10.0

The source data's URL is provided as the url parameter, and a radius of 10.0 kilometers is specified using the d (distance) parameter. Go ahead and get the result feed and display it using Google Maps.

Here are a couple more examples:

OpenContext projects feed, 200 km intersections

Geo-Annotated Reuters News feed, 100 km intersections

Interested? Feel free to try the user interface to the services at http://sgillies.net/mush.html.

Keep in mind that this service is just an educational toy. There's little support for asynchronous processing, and attempts to pull big feeds will certainly time out. Feeds with less than 50 or so intersections will be fairly responsive. YMMV. I'll try to keep it running as much as I can.

Intersection of 2 different feeds is obviously the next step.

Kurt Schwehr, who's making fink packages of OWSLib, Quadtree, and PCL-Core, is blogging about working on the Phoenix Mars Lander. Are these packages going to Mars, or helping from Earth? Let us know if the Lab can be of any assistance.

Update: more from Kurt.