Stop Using Mapscript

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.

Comments

Re: Stop Using Mapscript

Author: Christian

Hi M. Gillies, I am a programmer at the McGill University in Montréal, where I work on a GIS based surveillance and analysis system for TB cases. It's been a couple of weeks since I decided to use Mapserver for our system, and I am still prototyping it using a mix of PHP and Python Mapscript, PostGIS and the R statistical language. I am also studying the possible use of a dynamic client UI package (Ka-map seems an interesting one). Since I am a novice Mapscript programmer I had to gather infos about it from a variety of reference files and tutorials. I am satisfied with what I was able to achieve up to now, but I was quite intrigued today by your post with the advice that "we should stop using Mapscript" (I am reading your blog quite regularly by the way). I would like to know more about that idea of relying less on Mapscript, and more on the Mapserver DSL, through increased use of mapfiles. Could you expand on this change from the procedural paradigm to a more declarative one? Of course I woulndn't ask for a code tutorial, but I would like some more precise ideas, if you have time for that.

Start Using the Mapserver CGI Interface

Author: Paul Ramsey

90% of the stuff people are doing in Mapscript can be done just as well via the Mapserv CGI interface. Most of what Mapscript provides is the abilty to jimmy with settings in an existing mapfile, they hit the big red DRAW button. Well, you can do that just as well with the mapserv.cgi. Go here http://mapserver.gis.umn.edu/docs/reference/cgi/controls and then go right to the BOTTOM, to the obscure little section labelled "Changing map file parameters via a form or a URL". Then swear off mapscript for good.

Re: Stop Using Mapscript

Author: Sean

Paul, mapscripting via CGI query string is a smelly hack. On the other hand, you are right, it covers most of the same ground as mapscript.

Re: Stop Using Mapscript

Author: Paul Ramsey

Smellier than dumping mapfiles onto the filesystem and re-ingesting them? I would have thought using mapserver as a pure "web service" got more style points than the dump'n'read approach. A nice side-effect of my trick is that when you're deploying you can put your mapserv instance separate from your application server.