Federal Task Force Recommends Standards

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.

Comments

Re: Federal Task Force Recommends Standards

Author: Tom Kralidis

What a concept, eh! One can see this in two ways: 1./ Yes, decentralized and web services oriented, which definitely addresses distributed activities 2./ totally centralized, which also makes sense to an organization as an enterprise. The key factor is how an organization is setup IT-wise; do they have a centralized IT / publishing function? Or are these activites disparate? In either case, Web Services provide the obvious advantage of better chance at up to date / authoritative data, no matter what level they are deployed at within / between organizations.

Re: Federal Task Force Recommends Standards

Author: Dave Smith

Standards opens the door for both approaches to be taken. Without standards, a decentralized approach is the wild west. The hope is that the OMB beancounters recognize that governance is the most critical part to develop in the Geo Line of Business - all else turns into a cat-herding exercise.

Python 2.5, me Maties!

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.

Thar be Low-Hanging Booty

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.

Comments

Re: Thar be Low-Hanging Booty

Author: David Fawcett

Sean, A GUI-type interface for Frank's tools would be cool. I remember taking a course from Joe Berry in around 1999. He was using one of his own tools similar to model builder. No 'dis to Plone, but it would even more cool if this interface could run on a machine without having to install and set up Plone. David.

Re: Thar be Low-Hanging Booty

Author: Sean

David, what I'm talking about wouldn't require Plone at all. Just a UML designer that can export XMI, and a package -- inspired by ArchGenXML -- to parse it into Python code.

FRUGOS Meetup

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.

Discount Entry to GITR for FRUGOS

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.

How to Steal an Election

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.

GeoDRM at FOSS4G 2006

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.

mod_expires to the Rescue

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.