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
- Poorly researched
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?
A few years ago, J.F. Doyon and I collaborated on a Python package for programming with WMS and WFS called PyOGCLib. It found use in Thuban and a few other Python programs. I was never a happy PyXML user and so when I started up the Python Cartographic Library, took the opportunity to start over using ElementTree. My partner this time was Julien Anguenot of Nuxeo, and the driving force was the CPSGeo product for CPS. Last weekend I spent some time factoring our code out into a new project: OWSLib.
"OWS" is short for OGC(TM) Web Service. OWSLib is used by PrimaGIS to inspect WMS and WFS. It has a simple but effective capabilities document parser, and code for making web map context documents that probably has little use for anyone outside CPS at this time. WMC and SLD parsers are an obvious next step. There is a GML parser for PCL in progress which might also be of interest to OWSLib users.
OWSLib doesn't require the Python Cartographic Library. It depends only on ElementTree or lxml. Your choice. There's no official release yet, but I expect to have one in October in time for the Seattle Plone Sprint.
There's an Open Source GIS gathering at the SDSU Visualization Lab, August 8. For more details, see this post on mapserver-users.