Excellent! Kai's talk is accepted and on the Plone Conference agenda.

In my 200th post I wrote about the Pleiades project and our intent to be geospatial leaders for the Plone community and the digital humanities. Release early, release often is a part of the philosophy that Pleiades is porting from the open source software movement. Two months into the project, we're releasing a couple of simple and useful products for Plone: a geocoder, PleiadesGeocoder, and a map, PleiadesOpenLayers.

I'm not a regular podcast user, but stumbled across an excellent one last week. Yesterday, I listened in on John Udell's conversation with Peter Suber about open access. Suber's Open Access News is one of the very best sources for information about the OA movement. OA is somewhat related to the Open Source movement, but is concerned about content -- scholarly content in particular -- rather than tools.

Speaking of shakeout and convergence: I don't see any reason why Mapbuilder and OpenLayers, the two leading open source AJAX map libraries, need merge. Choice is good, and these projects offer distinctly different approaches. Mapbuilder is closely tied to GeoServer, highly structured, and disciplined. It's a natural fit for Java projects. OpenLayers, on the other hand, is simpler, XSLT-free, and more attractive to Python, Ruby, and PHP (if you must) users.

Python mapscript users have always been overwhelmed when they go shopping in the web frameworks aisle. It's long, and tall, and filled with mildly branded boxes. There's more options than one shop can possibly evaluate, and until the last year or so, none of them made much effort to jockey for the prime eye-level shelf. It's confusing. And the last thing your typical web GIS project needs is more confusion and more choices. You've already had to choose processors (Intel or Athlon), storage (IDE/ATA or SCSI), operating system (Windows, Fedora, Debian, Ubuntu, or ...), RAID configuration, raster tiling schemes, shapefiles or PostGIS, and so on. I really can't blame anyone at this point for taking the route clearly marked "PHP".

I was speculating wildly the other night that Google's regionator package has to have been written by Frank Warmerdam. The distracting capitalized method names are either a dead giveaway or a brilliant red herring. Regionator seems like a useful tool, but I'm less than excited about a couple aspects of it. There are tests -- good -- but they don't use unittest or doctest. Bad. Why invent yet another testing framework? Then there is the KML serialization:

kml = []
kml.append('<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n')
kml.append('<kml xmlns=\"http://earth.google.com/kml/2.1\">\n')
return "".join(kml)

Yo, Google, don't be a bozo. Use ElementTree (or lxml) infosets instead of managing all those tags and angle brackets yourself. You'll be glad you did, and you'll help to set a good example for hundreds of new Python programmers.

Nominations are open for the Sol Katz Award, which honors

... individuals who have demonstrated leadership in the GFOSS community. Recipients of the award will have contributed significantly through their activities to advance open source ideals in the geospatial realm.

I'm curious to see the nominees. The MapServer Foundation cabal members should consider disqualifying themselves. The NDA signed with Autodesk last year was a poisonous thing, and far from the ideals of open source community. It troubles me to say this because one of them is otherwise the clear choice for the award. The FOSS4G Pete Rose, you might say.

It's come to my attention that work is under way to separate access control of geospatial web services from digital rights management. A wise thing to do, and not only because GeoDRM is a non-starter. The access control problem has already been solved by the pioneers of internet commerce. If you don't believe me, go read the Apache httpd authorization and authentication docs. Anybody have an access use case that can't be solved by an Apache proxy, mod_rewrite fu, and tweaking of row/column privileges in your data store? It would have to be quite the corner case.

I lurk on the Mapbuilder email list and am growing uneasy at the project's flirtation with GeoDRM. In the wake of Sony's anti-customer technology meltdown the string "DRM" makes reasonable people shudder, but GeoDRM proponents soldier obliviously on. Five months after its release, I finally made the time to read the GeoDRM final report jointly produced by the FGDC, GeoData Alliance, and OGC. My conclusion is that it won't happen for at least four reasons. GeoDRM, as proposed, is:

• Overly complex

• Backwards-looking

• Poorly researched

• Unnecessary

Yesterday I wrote a Python module that uses the REST-ful Yahoo geocoding API. Coincidentally, Simon Willison announces today Yahoo's Python Developer Center with a few very similar recipes. It's another example of the ease of Python: there's usually one obviously right way to solve small problems. Check out the site for good examples of using the Yahoo APIs, but remember to skip over minidom and go straight to ElementTree. It's going to be in the standard library come 2.5, so why not get used to it now?