Digital Map Philosophy

[Steve Lime]

One other comment. Note that in some cases data and styling are bound
together so there is a real advantage to keeping them side-bt-side. For 
example, a user might apply an angle stored as an attribute (e.g. wind 
direction), or a color. Totally disjoint definitions make that difficult
to support.

In the end you need lots of flexibility to keep everyone happy. The
INCLUDE 
should help (note that you can nest INCLUDEs up to 5 deep). In addition,
there 
has  been some  discussion on supporting external SLD definitions as
well for 5.0. 

Steve

>>> Bill Thoen <bthoen at GISNET.COM> 12/31/06 12:03 PM >>>
I've been exploring MapServer for only a week or so, so maybe I'm
missing
something, but I have a problem with the LAYER philosophy that combines
the
data definition with the rendering style. I think these definitions
should
be physically separate, or at least there should be a way to redefine a
layer's graphic representation after the data have been associated with
a
named layer.

For example, I have a collection of styles that I prefer to use for
entities like roads, lakes and rivers, municipal boundaries, landmarks
and
so on. I actually have multiple sets that depend on the map scale and/or
the client or map purpose. 

But the data often come from different sources, or at least they require
different selections if you're drawing from a national data set for a
local area. To make the data-map interface consistent I also ensure that
the names, types and ranges of certain attributes are standardized (e.g.
I
have a field named 'class' for roads that contains standard values for
the
type of graphic representation I'll want for that road line, and for
street
name annotation, I use 'name' and 'route' and 'shield' for labeling
highways with route numbers above shield symbols). Using this convention
I
could simply cut and paste or INCLUDE the parts of a map file that apply
CLASS and STYLE parameters to my roads layer.

The problem I have with MapServer's LAYER definition in the map file is
that
I have to define the DATA selection parameters with the CLASS and STYLE
parameters. It seems to me that it would be more flexible to create
layers
by assigning the layer name to a data selection (and perhaps provide a
default graphic style) but then later in the map file apply a graphic
style
to the features for that layer. If that were possible I could build a
standard set of named base map layers and then simply apply a "style
file" through an INCLUDE statement that would set the symbology for each
standard layer. 

One of the "products" that I provide to clients is a map series for fire
departments in support of emergency planning, and it's important that
the
cartographic representation of map features be consistent and easily
recognizable. I can certainly do this with MapServer as it is now, but
I'll
either have to do a lot more (error prone) cutting and pasting or build
a
script to automatically generate map files for different map areas.

IMHO, the guiding philosophy should be that map content (points, lines,
polygons and annotation) be as separated from the styling as possible,
but
it seems that MapServer binds these elements together at the LAYER
level. I
think this belongs at the MAP level or at least there should be an
option
to do so at that level. The idea is similar to the philosophy that
applies
to html documents and css.

But like I said above, I'm pretty new to MapServer and maybe there's a
solution or convention I just haven't discovered yet. So what do people
do
when they want to produce consistent-looking maps over several MapServer
projects?

Happy New Year! 

- Bill Thoen