Geoff Zeiss writes:

Graduating OSGEO Incubation includes requirements for open community operation, a responsible project governance model, code provenance and license verification and general good project operation. Graduating incubation is the OSGeo seal of approval for a project and gives potential users of the project added confidence in the viability and safety of the project.

It looks like it is up to cranky old me to point out that of FDO's 17 committers, "haris" is the only one who is not an employee of or contractor to Autodesk. I'm not counting "timstrang", who has 1 commit for 0 lines of code. 13 Autodesk employees, 2 Autodesk contractors, and 1 independent committer.

Don't get me wrong, FDO looks like a technically excellent project, and they've done their best to do project business in the open and recruit new people. But it seems to me that it's failed to attract a diverse group of contributors. It probably would not have been graduated yet from an incubator like Apache's. Do non-diverse open source projects suck? No. I'm almost sole committer on several projects that kick ass, but I'll be the first to admit that they wouldn't be ready to graduate from the Apache incubator (even if they were accepted).

Maybe the real issue is whether the OSGeo brand is to represent standards as high as Apache's. It might represent lower standards, and that would be fine. Many entities happily used GDAL and GRASS before they were OSGeo branded. However, if the brand is supposed to be the equal of Apache's, OSGeo's "A for effort" incubation policy needs to be reconsidered.

Update: a reader says I was wrong to count mloskot as an Autodesk contractor. That would make 2 independent committers.

Howard Butler gives me something to pin on the Pleiades bulletin board (nothing motivates quite like adversity):

[...] I do have a lot of experience with Zope/Plone, and GeoDjango fills some big holes in the Zope stack when it comes to geospatial stuff that I don’t see ever being filled.

and then goes on to write all kinds of sensible stuff about GeoDjango. I'm not a GeoDjango user, but I've benefited from interaction with the developers. Justin Bronn inspired me to apply ctypes to GEOS (Shapely is in some sense a rip-off of GeoDjango, which was itself inspired partly by PCL's geometry package), and meeting him was one of my FOSS4G 2007 highlights. It's a worthy project.

The biggest reason to go with Django over Zope is, without a doubt, PostGIS: as a open source GIS developer/consultant you've already invested huge amounts of data and brain cells in Paul Ramsey's killer app while developing MapServer maps, and every single bit of this investment carries over into Django application development. You could say the same for Rails. None of your MapServer skills translate into Zope skills.

Of course, PostGIS can't help you at organizational boundaries, and Django doesn't provide "GeoWeb" services any more than Zope does. It's up to GeoDjango to develop WxS (or alternative) implementations.

Here's a disturbing thought: if only MapServer (the CGI program) implemented the Model-View-Controller pattern ... you wouldn't need GeoDjango at all. Or Django, for that matter. Use OGR as your connector to data (geospatial or not), and make entire dynamic "GeoWeb" sites entirely through mapfile configuration and CGI query string parameters.

I'm with Paul:

Summary: No matter whether you're building on ESRI or open source, if you are building something complex your staff will have to learn a few new skills. Their prior experience with core concepts like programming and IT will serve them well in both domains, and the learning curve will be no worse either way.

If your tech company doesn't have, or can't learn, the fundamental Javascript, SQL, and Java skills needed to deploy and run OpenLayers, PostGIS, and GeoServer (substitute C# and SharpMap for Java and GeoServer if you must), you'll be passed sooner or later by the companies that do.

4 nights, 4 Front Range cities, smells like Otto's jacket [1]:

• 2/19, Denver: Forest Room 5, 6PM-8PM

• 2/26, Fort Collins: the Bean Cycle, 6PM-8PM

• 2/27, Colorado Springs: Jack Quinn's Pub, 6PM-8PM

• 3/4, Boulder: Boulder Beer Company, 6PM-8PM

Keep an eye on the wiki for details.

Update (2008-02-11): Kurt Schwehr is thinking about Python code quality too.

Stalking "Python GIS" with Google's blog search led me today to this:

import arcgisscripting
gp = arcgisscripting.create()
gp.toolbox = "analysis"

# Set the workspace
gp.workspace = "c:\\Houston\\CrimeData"

# Call ListFeatureClasses
fcs = gp.ListFeatureClasses( )

#loop through the feature classes and buffer
fcs.reset()
fc = fcs.next()

while fc:
     outName = "buffered_" + fc
     gp.buffer(fc, outName, "500 Feet")
     fc = fcs.next()

What a joyless way to work with Python. The requirement that programmers call reset() and next() is also a sure recipe for bugs. Ideally, the "enumeration objects" would implement the iterator protocol, and you'd just do this:

>>> gp.workspace = r"c:\Houston\CrimeData"
>>> for fc in gp.ListFeatureClasses():
...     outName = "buffered_" + fc
...     gp.buffer(fc, outName, "500 Feet")

Better yet, you're not going to need to pass an argument into the enumeration factory, so replace it with a property:

>>> gp.workspace = r"c:\Houston\CrimeData"
>>> for fc in gp.featureClasses:
...     outName = "buffered_" + fc
...     gp.buffer(fc, outName, "500 Feet")

Tight. Of course, I've got plans to do it even better in a future release of WorldMill. Something like:

>>> inws = mill.workspace(r"c:\Houston\CrimeData", "r")
>>> outws = mill.workspace(r"c:\temp", "w")
>>> for cname, collection in inws.items():
...     outws.add(buffer(collection), "buffered_" + cname)

Windows users: save on slashes by using Python's raw (r) strings as I did above.

A bug fix release: Shapely 1.0.1. Now you can safely use highly condensed operation-chaining expressions like this one:

Python 2.5.1 (r251:54863, May  2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> from shapely.geometry import Point
>>> numpy.asarray(Point(0.0, 0.0).buffer(1.0).boundary.coords)
array([[  1.00000000e+00,   0.00000000e+00],
       ...
     [  1.00000000e+00,   0.00000000e+00]])

Back to business now. One of the surest ways to tell if there is any Web in a "GeoWeb" site is hit Ctrl-U. I just did that for http://serverx.esri.com/ArcGISJavaScriptAPI/SuperTuesday.html and I like what I see so far.

As I told Matt Priour, I know for a fact that there are developers at ESRI who get REST. Several are posters to the Geo-Web-REST group. It's clear from the demo that there is resource-oriented thinking going on at ESRI. Consider this map layer home page that you can find through the demo source: SuperTuesdaySample/MapServer/1. There you find metadata and links to subordinate resources such as a query. The HTML representation of the query is a form which doubles as a query description. I am 100 percent in favor of this approach; it's exactly what I've done with Mush. Traverse upward from the layer to the map server resource and you'll also find WSDL and a JSON service description. I'm not against service descriptions at all, but I wonder why not WADL? Or for that matter, why not OWS Capabilities?

This is good stuff. I'm curious to see how the PUT, DELETE, and POST story goes.

Postscript: Looks like James Fee beat me to "view source".

Bam! Something just hit the window here. Looking out, I saw this Sharp-shinned Hawk nail a Starling.

I can't decide which feels more liberating: posting amateur bird photos, or writing about electoral politics.

Democrats caucus in Colorado. I've been a slacker about attending these in the past because the nomination has already been decided before the caucus date since I moved here in 1993. It looks like it's going to be an interesting process. At the very least I'll get to hang out with my activist neighbors for the evening and visit the Junior High School that my daughter would attend should we stay in this end of Fort Collins.

I would have liked to see Republicans pick a kook like Huckabee or a patent phony like Romney, but it seems like they are going to select the strongest of their options after all. McCain doesn't demonize minorities and immigrants, he's not anti-science, he's sensible about climate change and the environment, he's taken a stand against state use of torture (including the shameful and criminal torture practiced by agents of the US), and the media fluffs him like there's no tomorrow. He can run hard to the center in the general election without losing credibility with the right-wing base -- he's got the magical "Maverick" card -- and that will make him extremely hard to beat.

While McCain may be less terrible than his peers, he's still far from me on important issues, and I'll be voting against him. For me, the choice of who to vote for comes down to "electability". I admire both Clinton and Obama, but I think Obama is the better Democratic candidate this year, this campaign. His youth contrasts well against McCain's age, and I can't help but feel that the Republican base won't fire up against him quite as hotly as they would against Clinton. It's going to be a close election, and every single-issue Clinton-hating voter that stays on the bench counts.

Ha! The Denver Post feels differently about McCain. Probably a Colorado River rivalry thing.

The transition of chicagocrime.org has been noted by geo-bloggers, but they are missing a key part of the story: the resources that had been hosted on chicagocrime.org are not dead at all. They have been moved to a new host. Their original URLs have been retired, but the resources themselves carry on. I'm not speaking figuratively. Stability is a virtue, but Web architecture makes it possible for resources to move when necessary. The chicagocrime.org move is a perfectly ordinary transition of resources on the Web.

How is this accomplished? Requests for http://chicagocrime.org are redirected to http://everyblock.com. I don't mean that you get a web page that says, "click here to go to the new web site". I don't mean that http://chicagocrime.org is maintained as a proxy server for content from http://everyblock.com. I mean that the Chicago Crime host responds to your request with a 301 Moved Permanently response:

sean@lenny:~$ curl -v http://chicagocrime.org/
* About to connect() to chicagocrime.org port 80
*   Trying 64.207.128.91... connected
* Connected to chicagocrime.org (64.207.128.91) port 80
> GET / HTTP/1.1
> Host: chicagocrime.org
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/0.5.35
< Date: Tue, 05 Feb 2008 16:57:32 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: http://chicago.everyblock.com/crime/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/0.5.35</center>
</body>
</html>
* Connection #0 to host chicagocrime.org left intact
* Closing connection #0

That response tells user agents that the resource formerly found at http://chicagocrime.org/ has been moved to http://chicago.everyblock.com/crime/, and that user agents may consider it to be the same resource. Its representation ("format" to you GIS folks) may have changed a little bit, and the less the better for non-human users, but it should be substantially the same. Somewhat smart user agents, like your web browser, will follow up on this response with a request to the new resource location, making the redirect more or less invisible to you. Smarter user agents might update their bookmarks accordingly.

Look a little more deeply and you'll notice that not only has the root resource been permanently moved, the descendent resources have been moved as well:

sean@lenny:~$ curl -v http://www.chicagocrime.org/zipcodes/60615/
* About to connect() to www.chicagocrime.org port 80
*   Trying 64.207.128.91... connected
* Connected to www.chicagocrime.org (64.207.128.91) port 80
> GET /zipcodes/60615/ HTTP/1.1
> Host: www.chicagocrime.org
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/0.5.35
< Date: Tue, 05 Feb 2008 17:11:30 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: http://chicago.everyblock.com/locations/zipcodes/60615/
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/0.5.35</center>
</body>
</html>
* Connection #0 to host www.chicagocrime.org left intact
* Closing connection #0

Browse to http://www.chicagocrime.org/zipcodes/60615/ to see this in action. Starting with a sane URL scheme as Chicago Crime did certainly makes the transition a lot easier.

I can't say for sure that every single resource from chicagocrime.org has been moved in this way, but it wouldn't surprise me if they have, and if it took no more than 20 lines of configuration on the old server. By the way, HTTP specifies a status code that can be used to tell user agents that a resource really is no more: 410 Gone. I wouldn't be surprised if that was employed somewhere on what's left of chicagocrime.org.

Chicago Crime resources are moved, the Web as an application goes on without missing a beat. At least the pieces of it that were only loosely coupled to http://chicagocrime.org; any script that was downloading resources from the old site without following redirection is well and surely (and perhaps rightly) broken. Geographic sites and services can migrate or evolve using the same mechanism, a mechanism that is built into the Web. Does your GIS "web" service client understand redirects, or is it crazy-glued to those service endpoints?

All of the above is elementary web knowledge, but the Chicago Crime move is a nice lesson in applying resource-oriented thinking to a "GeoWeb" site.

rewrite ^/zipcodes/(\d+)/?$ http://chicago.everyblock.com/locations/zipcodes/$1/ permanent;