THL Toolbox > Developers' Zone > Gis Development > Methods Of Symbology Management
Methods of Symbology Management
Contributor(s): Tom Benner
When using an OpenLayers map that uses WMS layers to display features, the symbology of the map will be handled by SLD, which is like CSS for geospatial data except much more powerful (e.g. you can establish styling rules based on attributes of the data). There are basically three options of managing the styling rules for features, which differ in how they link feature types to certain styles. They differ greatly in initial investment vs. long-term maintainability/scaling.
(In this context, "style rule" means a defined set of style attributes, like "stroke width", "stroke color", "fill color", "point image icon", etc.)
1. Feature type IDs in the SLD
This would involve setting up an SLD file that has a default style for all points, lines, and polygons, as well as custom styles for specific feature types. To link the custom styles to their corresponding feature types, the IDs of the feature types would need to be listed in this file next to their corresponding style's definition. The file might consequently become a bit difficult to manage if many custom styles are used, since it would consist of a long list of style rules, each with a list of IDs, and doing manual editing with IDs is often a bad idea.
2. Styles based on a style rule ID in the Feature Thesaurus
A field would be added to the Feature Thesaurus that lets one assign a style rule to each feature type (there could be a default style rule for all feature types that was set by default). In GeoServer, each feature has a style rule ID, which is the style rule ID that their feature type has been assigned in the Feature Thesaurus. The SLD file reads this style rule ID and styles the feature in the corresponding style rule. The style rules would be hard-coded into the SLD, so to, say, make nations have green boundaries, one would need to edit the SLD.
3. Web interface for editing style rules
A web interface for editing style rules could be made. There would be a table of style rules, each one having have fields like "stroke width", "stroke color", "fill color", "point image icon", etc, which can be edited in the interface. Each feature type would be assigned a style rule through the interface. In GeoServer, each feature would have these attributes, which it would inherit from the style rule that its feature type is linked to. The SLD file would be very simple; it would just look at the attributes of each feature and use those attributes to style it.
So, 3 requires the most investment up front, but it is the easiest to maintain in the long run, especially there are many style rules. 1 requires no initial investment, but may be difficult to maintain if there are many style rules. 2 lies between 1 and 3 in this respect.
