MapServer Anti-Patterns

Reviewing recent threads on the mapserver-users list during a chat with a new MapServer user on IRC, I had a modest eureka moment: these particular struggles aren't just isolated cases. These are anti-patterns, patterns of thinking about MapServer that lead to inefficient or broken applications.

Death by a Thousand Classifications is my name for the common overuse of MapServer's feature classification mechanism. The classic case arises when users begin with TIGER lines (perhaps an anti-pattern all its own) and attempt to create separate freeway, highway, and road map layers by classifying on the "CFCC" attribute and throwing away all the features that do not match. The more of these single-class layers the user adds, the more expensive the map. The proper solution to the problem of creating multiple layers from a large dataset is to pre-process the data into separate files or feature tables.

Data Mutation is the anti-pattern that I perceived in this morning's chat. The user wants to have a mutable classification scheme; depending on parameters of a map request some set of counties (in this case) are rendered by the styles of class A and the rest by the styles of class B. The user's solution was to keep the classification rules fixed and instead change the attribute values of data features. Data Mutation is never the right solution to a tricky MapServer problem. First of all, it's unwise to give the MapServer user account write privileges on data. One could work around this by rendering from a temporary copy of the master data, but then there's extra overhead. Lastly, if the Data Mutation anti-pattern is followed, the application will not be able to easily switch to new data sources such as replacing shapefiles on disk with PostGIS or WFS. These features come over the wire and can't be mutated.