It's an improvement over the abysmal ArcIMS client, for sure, but is less impressive than all the hype suggested. The HTML table of operation panes looks and feels clunky. Reordering the panes conflicts with Firefox's right-click menu. The scale bar is nowhere near as sexy as Tim Schaub's (in PrimaGIS and OpenLayers), and the scale slider is nowhere near as smooth as the one in Google Maps. I was expecting it to feel more usable and look more appealing.

There is a request in comments for more details and examples of declarative programming with MapServer. Before I elaborate, I must stress that I'm advocating a new-ish, different way of looking at MapServer. It's not widely recognized that the instructions encoded in a MapServer mapfile comprise a domain-specific language. (Norman Vine, for one, gets it.) The reference itself is concerned only with the content of a configuration file, and doesn't acknowledge the existence of a language. Like it or not (and I do have my issues with the syntax and semantics of it), there is a map language. To embrace the map language is to benefit from simplicity, usability, and portability. Now, don't misunderstand, there's nothing inherently wrong with imperative programming. The problem is that imperative mapscripting exposes its practitioners to the many rough edges and pitfalls of MapServer's internal API, and produces less than portable applications.

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).

Good post from Pete Lacey about how much of the IT industry can't hear the victory cheers. Thanks largely to Google, the situation is better in the geospatial business. Google Maps and Earth have utterly breached the firewall in our industry. Only the deepest of the deep corporate spider-holes could hide a geospatial developer from un-enterprisey ideas like the GMaps API, KML, GeoRSS, and REST.

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.

Place names and class of names are the main points of our upcoming Pleiades milestone, so it's an interesting coincidence to hear about Barry Lopez's book about landscape words on NPR the other evening. Reading the excerpts, I became a little sentimental about the names of my favorite landscape, the Colorado Plateau: slot canyon, dry fall, reef, arch, tank, water pocket.

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

That's nuts.

I've always done a poor job of explaining what these software sprints are all about. Jon Stahl does a much better job here. If you look closely you will see my chin in the very upper left corner of the fifth photo in his blog entry, sitting just behind Jackie, Martin, and Alexander.