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 <[EMAIL PROTECTED]> 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
