La Mort du Tour

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.


Re: La Mort du Tour

Author: Matt Perry

Vino getting kicked out for doping .. that's just pathetic. I really wanted to root for his incredible roller-coaster comeback. Now his great rides are completely nullified. But Rasmussen getting fired for missing a few drug tests (and lying about it). Come on! The guy has tested clean all tour .. at least let him finish the race instead of pulling him out immediately after his victory at the Col-d'old-beast.

Re: La Mort du Tour

Author: Sean

Naturally, Vino should be punished by crushing.

Re: La Mort du Tour

Author: Andrew Larcombe

Cycling is the most tested sport, more people are being caught, and if they lie about there whereabouts to get out of being tested out of competition (as it is believed The Chicken did) one can only assume they're trying to cheat the system. In 1998 riders were protesting against the introduction of drugs testing. 2007 they're protesting against the cheats. We're seeing a purge, not a meltdown.

Re: La Mort du Tour

Author: Matt Perry

Andrew, That is true.. the pessimist in me thinks the sport is in a downward spiral while the optimist wants to believe that this is a "good thing" and that, as they continue to crack down, the sport will be rid of the cheaters. One can hope.


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.

Geo at Plone4Artists Sprint

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.


Re: Geo at Plone4Artists Sprint

Author: Yves Moisan

"GPS-tagged digital photos". I've seen there are gadgets that allow one to GPS-tag one's photos, but is that mainstream technology ? If so, I guess all it does is attach a coordinate to the point where the photograh was taken, so the GPS info with respect to the photograph *content* is only exact if one is taking a picture vertically down looking at the ground with a FOV print that approximately covers GPS x-y uncertainty ;-). Are there ways to include also a line of sight bearing and a FOV, the first being the locational device's responsibility (some electronic compass with the GPS unit?) and the second being the responsibility of the camera (some function of the zoom level) ? I guess bearing information could be derived by the user purposely walking straight ahead a few 10's of meters in the direction he wants to take a picture and then shoot. Zoom level, I don't know. With that additional info, the GPS point would be the apex of an irregular polygon more or less matching the content of the picture. That polygon could then be used in spatial searches to find out which pictures cover some ground area. Just thinking out loud.

Re: Geo at Plone4Artists Sprint

Author: Sean

Yves, there are GPS-equipped cameras on the market that write the location of the device to the image headers. Not cheap, but certainly mainstream. Good points about the field of view. I don't think David and Sally are trying to solve that problem.


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.


Re: Games

Author: Ed Parsons

I think a key part of the Tom Tom deal is automation, and the potential for the community to update data and provide statistical traffic information while just driving.. I agree for active user input fun needs to be a big part of the motivation !!

Re: Games

Author: Yves Moisan

Ed says : "for active user input fun needs to be a big part of the motivation" I wonder if "data collection sprints" leisure activities as in folks doing geocaching could be feasible? A lot of folks have spare time they'd like to volunteer for, so there could be lists of problems to tackle e.g. "delineation of marsh areas in NW Minnesota" that could act as nucleation centers for community activity. Where to put those lists and how to manage them is another ball game. As a first step, government departments in need of data could call upon their citizens for fun data collection parties :-)

Going Big

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.

Web Geo-Processing, Pull Style

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 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 You pull another feed through it via a URL like:

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

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.


By ref + by value

Author: Keyur

Sean, Taking url as input works great for someone who has the web infrastructure (a public web server among other things) at their disposal - I call this the "parameter by reference" approach... But for casual users without this infrastructure, it'd be handy to also allow the value directly in the parameter - "parameter by value". Of course, parameter by value does not work for large datasets - you have to do parameter by ref for such cases or do a POST... But for users who are trying to do simple things (ex. buffer a single point) it works very well. Cheers.

Re: Web Geo-Processing, Pull Style

Author: Sean

You can say "parameter by reference"; I'll say "pull".

Re: Web Geo-Processing, Pull Style

Author: Kyle

Wow... a very cool gp tool you have here. This gets me so excited for what's to come on this new frontier!