Good sense prevails! A task force reviewing federal GIS recommends that the best strategy for consolidation is standards not centralized services. Like the web itself. Via All Points Blog.

What's in the brand spanking new Python 2.5 for geospatial folks? New standard libs:

• ctypes: call functions exposed from DLLs and shared libraries. This gives us an even more direct way to leverage geospatial libraries than SWIG does.

• ElementTree: the natural way to program with XML now ships with Python.

• cProfile: I've been using the slow profile.py quite a bit in developing the Python cartographic library. This more efficient module comes out of Google's Summer of Code.

Completed PEPs:

• 341: Consistent exception handling -- finally.

• 343: Context management not unlike Ruby blocks.

Python 2.5 is also significantly faster than 2.4, string programming in particular.

I was sending an email to the FRUGOS list about data processing with GDAL and OGR, and wrote that there is low-hanging fruit in the form of an open source graphical data processing model builder. One attendee of last week's meetup said that the ArcGIS model builder was the only thing he couldn't do without. I met another open source GIS user this summer who also expressed an appreciation for the model builder despite the overall awkwardness of the geoprocessing tool. People love GDAL and OGR. People love graphical modeling. I think we can have these and the benefits of open source as well.

For the Pleiades project we are authoring custom Plone content types using ArchGenXML. We design the content package and its classes using ArgoUML class diagrams. ArchGenXML parses the exported XMI file and creates Plone Archetype based classes -- Python code and scaffolding. ArchGenXML is a remarkable product, allowing someone with no specific Python skill to produce functional Python packages for use in Plone. I believe it would make an excellent starting point for a graphical data processing modeler:

1. Create a activity diagram in ArgoUML.

2. Export to XMI.

3. Parse, adapting the ArchGenXML code, and generate Python modules using gdal.py and ogr.py to execute the diagrammed processes.

The result: a highly portable, visually documented, open source, data processing package.

The FRUGOS meetup at GIS in the Rockies organized by Brian Timoney was a success. Agencies were well represented: DOE's Western Area Power Administration, DOD (through Booz Allen Hamilton), USGS, and BLM accounted for half the attendees, and this is where the regional open source GIS expertise is found. Booz Allen Hamilton and WAPA use MapServer alongside ArcIMS. The USGS folks are using OSSIM and SPRING. The Bureau of Land Management, on the other hand, is an untracked backcountry slope. These folks are interested, but the Bureau doesn't give them the kind of latitude enjoyed by coordinators and programmers at the USGS, NOAA, or NASA. We all agreed that success stories from other agencies are going to help open source into BLM like nothing else.

I'd have guessed that people under 35 have always been the major innovators in society. Congratulations, Joshua Schachter! Via Boing Boing.

According to Tom Kralidis, Markus Neteler has received the 2006 Sol Katz Award. Markus well deserves this recognition.

Brian Timoney has good news for people who weren't sure about paying full admission:

Mike Greer, chair of GIS In The Rockies, has generously agreed to allowing anyone who would like to come to Thursday's meeting (at 11:15AM, Rm. 423), to attend under the $25 Exhibits-only admission price.

See you tomorrow at Invesco Field.

Public service announcement.

Regardless of your personal party affiliation -- if you're interested in whether or not your vote counts in future elections, you owe yourself a viewing of the video at Princeton's Center for Information Technology Policy, wherein it is demonstrated that Diebold's poorly engineered system makes stealing an election trivial. The USA's completely borked electoral college system makes us particularly vulnerable. Via Boing Boing.

Here's a talk I'd like to see: GeoDRM: Keeping Free and Remaining Open. An excerpt from the abstract:

One of the most important use cases involves assuring that free and open data in fact remain unencumbered, for example by liability or derivation claims.

The open data movement needs GeoDRM? To me, this is prima facie nonsense. I'm interested to find out what Jo and other open data advocates attending the conference take away from this talk.

OpenLayers and MapBuilder apps each require download of a mass of javascript, and a significant wait. Developers are looking into javascript on demand, which is interesting, but the problem is pretty much solved in most cases by Apache's mod_expires. Drop this .htaccess into your javascript library root:

ExpiresDefault "access plus 1 month"

and your clients will cache the bulky javascript for up to a month.

Update: this works better if you're using the single-file build of OpenLayers.