2006 (old posts, page 12)

Atom feed RSS feed

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.