In the comments of James Fee's AGX vs GE post (and others), ESRI users cling desperately to the mantra that ArcGIS Explorer and Google Earth do different things and aren't competitors. However, as Stephen Geens notes (at the end of this post), Google Earth users with a serious GIS background are ready, willing, and able to compete with AGX and ArcGIS services.

You might not care that I don't read corporate or team blogs, but maybe you'll pay attention to Jeremy Zawodny or Joe Duck.

Via Steve's Little World (which also features a worthy rant).

I didn't expect it to happen at all, but Eben Moglen's keynote address at the Plone Conference moved me. I admit that it's easier to do these days now that I'm a parent and feeling sappy. (How sappy? My wife and I almost lost it at the end of Peter Jackson's King Kong, that's how sappy.) I want my daughter to grow up in a more free, more fair, better world, and I'm proud to consider that my work on free software is helping to make that better world possible.

My favorite stretch of the keynote is where Moglen asks us to consider a world of proprietary math. Imagine that you can only use as much math as you can afford. Multiplication and division might be too expensive for the poor or underemployed. The means to solve simultaneous PDEs might be beyond all but the most wealthy.

What if Newton or Liebniz had been inclined and able to lock up Calculus with a proprietary license? Developments in the field of Mathematics would have slowed to a crawl, hamstringing the Enlightenment. What if Legendre had locked his Transform with a proprietary license? Mathematical Physics would never have flourished. There'd be no electronics, no atomic theory, no computers, no iPods. We'd be sitting around complaining about the price of newspapers and oil to keep our lamps lit.

According to Moglen, this is where we are at today with regards to software. Watch him make the case for free software in large (YouTube) or massive format (archive.org).

Stop using MapScript. I recently gave this advice to an email correspondent, and I'm repeating it here for my readers. Cease, or at the very least, minimize your use of MapServer's various language bindings. Instead, embrace MapServer's domain-specific language (DSL) and write more of the declarative cartographic scripts known as mapfiles. Use the mapserv (or shp2img) program to compile these scripts into images. This is the path to happiness and prosperity.

A common complaint of the mapscript programmer is: "My program runs N times slower than the MapServer CGI". Of course it does. MapServer's code has been stressed and optimized over the years. It's faster and less buggy than anything you're going to write without serious effort.

MapServer's scripting APIs are inconsistent and not well documented, not friendly to the user. On the other hand, your favorite programming environment bristles with excellent tools for creating text documents such as a MapServer mapfile. Ed McNierney has long advocated the use of C preprocessors to generate mapfiles. A fine example for Python is Allan Doyle's ElementBuilder-based mapfile builder. I would be surprised if Ruby's Builder couldn't be extended in a similar fashion.

Another reason to embrace MapServer's DSL is the reasonable expectation that tools will evolve to port your MapServer mapfiles to other applications. Good luck getting help to port your thousands of lines of custom mapscript code to PrimaGIS, Mapnik, or MapGuide.

MapServer has but one obstacle to programming in such a completely declarative style: you can't pipe in a script. The script must be a file on disk (hence the "file" in mapfile), and this requires an often unnecessary I/O round trip. For the same reason, Allan has to write his mapfiles out of Python to disk before he can load them again into mapscript map objects: maps can not be instantiated from strings.

Why do these limitations persist in MapServer? Because developers lost the declarative trail when they found mapscript. Among them, I was caught up in writing too much code with mapscript.py. From a distance, it's clear to me that I overlooked many of the benefits of using MapServer in a completely declarative style.

"Man says reusable modules are ok and all, but cutting and pasting code snippets is way better."

That's nuts.

I just finished making a map of Tanacetum vulgare (Common Tansey) incidence for a visiting ecologist. I learned to do this kind of task with ArcView 3 back in the previous century, but left the data processing and analysis business before my employer upgraded. This means I never really tried out ArcMap until now. I must say that it's perfectly adequate for this kind of task, allowing me to add a new attribute to features and hack away at the attribute table using search and replace. A scriptable interface to the symbolization would be nice, but the provided tools are not too bad. Everything I remembered about good ole ArcView 3.2 seemed to transfer right over to use of ArcMap 9.1. The whole thing, not including the time to find and download decent data (North American Framework from GeoGratis) took about 20 minutes. There's no greater message to this story, I just feel that I owe the blogosphere a report of a good experience I've had with proprietary GIS software.

There's an accurate, well-written article on geospatial open source by Christopher J. Andrews in Directions Magazine. In the last paragraph, Andrews writes.

With the liberal licensing on some geospatial OSS, I hope an industrious company will develop a 'map server in a box' appliance. Such an appliance, coupled with a basic methodology to package up an organization's available data, would greatly accelerate the adoption of geospatial OSS and further decrease the TCO for geospatial open source.

People having been talking about mapservers or spatial data infrastructures in a box for a while. It's bound to happen any day now, but almost certainly without the box, instead using "elastic" arrays of virtual machines.