Symbology Encoding (SE) specifies the format of a map-styling language that can be applied to digital feature and coverage data to produce geo-referenced maps with user-defined styling.
The importance of the visual portrayal of geographic data cannot be overemphasized. The skill that goes into portraying data (whether it be geographic or tabular) is what transforms raw information into an explanatory or decision-support tool. Fine-grained control of the graphical representation of data is a fundamental requirement for any professional mapping community.
The Symbology Encoding (SE) specification has been developed by the Open Geospatial Consortium (OGC)®.
Additional Information – Symbology Encoding (SE)
Development of the SE Specification
Originally SE was part of the Styled Layer Descriptor (SLD) Specification, but in 2007 the SLD was split into two new specifications:
- Styled Layer Descriptor (SLD) Profile of the Web Map Service Implementation Specification; and
- Symbology Encoding Implementation Specification.
The Styled Layer Descriptor Specification now only contains the protocol for communicating with a Web Map Service (WMS) about how to style a layer. The actual description of the symbols in the layer is now exclusively described here, and in the Symbology Encoding Implementation Specification. This allowsthe symbology not specific to WMS to be reused by other map service specifications, such as the Web Feature Service (WFS) and Web Coverage Service (WCS).
Map Styling Using SE
Symbology Encoding (SE) defines an XML Schema that can be used for styling feature and coverage data. These styles apply either to specific feature types or coverage types, depending on the used data type.
Because Symbology Encoding is a grammar for styling map data independent of any service interface specification, it can be used flexibly by a number of services to style geo-referenced information or store styling information that can be used by other services.
The SE approach follows the OGC® web service model and considers symbolization as participating in a distributed operation in addition to a centralized operation supported by most GIS products. Therefore, it becomes possible to request a single integrated map over the web that would be dynamically created and composed of features coming from a large number of data sources, and to obtain a coherent map even if map servers delivering portions of the map have been acquired from different vendors.
The Web Map Service (WMS) specification supports the ability for an information provider to specify very basic styling options by advertising a pre-set collection of visual portrayals for each available data set. However, while a WMS can provide a user with a choice of style options, the WMS can only tell a user the name of each style; it cannot tell the user what the portrayal will look like on the map. The ability for a human or software client to define these rules requires a styling language that the client and server can both understand. This standardized language, called Symbology Encoding (SE), can be used to portray the output of a Web Map Service, a Web Feature Service, or a Web Coverage Service.
Feature and Coverage Elements
Symbology Encoding defines elements used for rendering both features and coverages. The root element of a specific Symbology Encoding is, therefore, a FeatureTypeStyle or a CoverageStyle. These elements include all information for styling the data, such as Filters (to include/exclude data) and different kinds of Symbolizers. Following are a number of elements used throughout Symbology Encoding (SE):
- The Name element is used with most “objects” defined by SE, to allow them to be referenced. Names must be unique in the context in which they are defined.
- The Description element is also used throughout SE, and gives an informative description of the “object” being defined. This information can be extracted and used for such purposes as creating informal searchable metadata in catalogue systems. More metadata fields may be added to this element in the future. Note that the Nameis not considered to be part of the Description since a name has a functional use that is more than just descriptive.
- The OnlineResource element is used in various places in SE, to refer to external documents. The most common usage pattern is to use the xlink:type and xlink:href fields to refer to a simple link, as in:
<OnlineResource xlink:type="simple" xlink:href="http://somesite.com/something.xml"/>
A frequent semantic for an OnlineResource that refers to an XML file is to process the content as if it appeared directly in-line.
A brief overview of the elements that comprise the two root elements of SE, FeatureTypeStyle and CoverageStyle, is presented below. Additional details of the elements that comprise SE are included in the Symbology Encoding Implementation Specification.
The Version is an optional attribute of the FeatureTypeStyle element that identifies the SE version number to which theFeatureTypeStyle corresponds.
A FeatureTypeStyle can have a Name and a Description. The Description is for human-readable information. Optionally, the Name element may be used to reference a FeatureTypeStyle in some feature-style library.
The FeatureTypeName identifies the specific feature type that the feature-type style is for. It is allowed to be optional but only if a feature type is in context, or if it is intended for use with a number of feature types using a SemanticTypeIdentifier.
The SemanticTypeIdentifier is used to identify what the feature style (or Coverages in case of usage inside a CoverageStyle) is suitable to be used for, using community-controlled name(s). For example, a single style may be suitable to use with many different feature types. The syntax of the SemanticTypeIdentifier string is undefined, but the strings “generic:line”, “generic:polygon”, “generic:point”, “generic:text”, “generic:raster”, and “generic:any” are reserved to indicate that a FeatureTypeStyle may be used with any feature type with the corresponding default geometry type (i.e., no feature properties are referenced in the feature style).
The FeatureTypeStyle contains one or more Ruleelements that allow conditional rendering. A Rule can either be in-line or referenced by an OnlineResource.
The CoverageStyle defines the styling that is to be applied to a subset of Coverage data.
The CoverageStyle can have a Name, Title, and Abstract. The Title and Abstract are for human-readable information. Optionally, the Nameelement may used to reference a CoverageStyle in some coverage-style library.
The CoverageName identifies the specific coverage that the coverage style is for. It can be optional, but only if one coverage is in-context and that coverage must match the syntax and semantics of all coverage-property references inside the CoverageStyle.
Rules are used to group rendering instructions by feature-property conditions and map scales. Ruledefinitions are placed immediately inside of FeatureTypeStyle or CoverageStyle definitions.
The Description elements give the familiar short title for inclusion on display lists, and a longer description for the Rule. Rules will typically be equated with different symbol appearances in a map legend, so it is useful to have at least the Title in the Description so it can be displayed in a legend. The Name element allows the Rule to be referenced externally, which is needed in some methods of SE use.
Embedded inside Rules are Symbolizers which describe how features will appear on a map. The Symbolizer describes not just the shape that should appear but also such graphic properties as color and opacity. A Symbolizer is obtained by specifying one of a small number of different types of Symbolizers and then supplying parameters to override its default behaviour. Five types of Symbolizers are defined, and are described in the Standard using SVG/CSS2 terminology and syntax as appropriate:
- A LineSymbolizer is used to style a “stroke” along a linear geometry type, such as a string of line segments, and comprises the following elements: Geometry, Stroke and Perpendicular Offset.
For example:Consider that there is a layer defined with all the features of the type ‘River’ that is to be displayed as a blue line two pixels wide. Here is the example LineSymbolizer:
<LineSymbolizer> <Geometry> <ogc:PropertyName>centerline</ogc:PropertyName> </Geometry> <Stroke> <SvgParameter name="stroke">#0000ff</SvgParameter> <SvgParameter name="stroke-width">2</SvgParameter> </Stroke> </LineSymbolizer>
- A PolygonSymbolizer is used to draw a polygon (or other 2D-area geometries), rendering an interior “fill” and an outlining “stroke”, and comprises the following elements: Geometry, Fill, Stroke, Displacement and Perpendicular Offset.
For example: Consider a ‘Lake’ feature type with a Polygon property called ‘geometry’ that we wish to symbolize as a ‘light-blue’ filled polygon with its boundary drawn as a ‘dark blue’ line. The lake can be filled and its boundary drawn using the PolygonSymbolizer, as follows:
<PolygonSymbolizer> <Geometry> <ogc:PropertyName>the_area</ogc:PropertyName> </Geometry> <Fill> <SvgParameter name="fill">#aaaaff</SvgParameter> </Fill> <Stroke> <SvgParameter name="stroke">#0000aa</SvgParameter> </Stroke> </PolygonSymbolizer>
- A PointSymbolizer is used to render a “graphic” at a point, and comprises the following elements: Geometry and Graphic.
For example: Consider symbolizing ‘Hospital’ features that have a point geometry property called “locatedAt” as solid red stars centered on the hospital locations. The PointSymbolizer can be represented using a mark as follows:
<PointSymbolizer> <Geometry> <ogc:PropertyName>locatedAt</ogc:PropertyName> </Geometry> <Graphic> <Mark> <WellKnownName>star</WellKnownName> <Fill> <SvgParameter name="fill">#ff0000</SvgParameter> </Fill> </Mark> <Size>8.0</Size> </Graphic> </PointSymbolizer>
- A TextSymbolizer is used for styling text labels, and comprises the following elements: Geometry, Fill, Label, Font, Label Placement and Halo.
For example: Consider displaying the value of a “hospitalName” property of hospital features as a label. Here is an example TextSymbolizer:
<TextSymbolizer> <Geometry> <ogc:PropertyName>locatedAt</ogc:PropertyName> </Geometry> <Label> <ogc:PropertyName>hospitalName</ogc:PropertyName> </Label> <Font> <SvgParameter name="font-family">Arial</SvgParameter> <SvgParameter name="font-family">Sans-Serif</SvgParameter> <SvgParameter name="font-style">italic</SvgParameter> <SvgParameter name="font-size">10</SvgParameter> </Font> <Halo/> <Fill> <SvgParameter name="fill">#000000</SvgParameter> </Fill> </TextSymbolizer>
- The RasterSymbolizer describes how to render raster or matrix-coverage data, such as satellite data and DEMs), and comprises the following elements: Geometry, Opacity, ChannelSelection, OverlapBehavior, ColorMap, ContrastEnhancement, ShadedRelief and ImageOutline.
For example: The following coding applies a coloring to elevation (DEM)data (quantities are in meters):
<RasterSymbolizer> <Opacity>1.0</Opacity> <OverlapBehavior>AVERAGE</OverlapBehavior> <ColorMap> <<Categorize> <LookupValue>Rasterdata</LookupValue> <Value>#00ff00</Value> <Threshold>-417</Threshold> <Value>#00fa00</Value> <Threshold>-333</Threshold> <Value>#14f500</Value> <Threshold>-250</Threshold> <Value>#28f502</Value> <Threshold>-167</Threshold> <Value>#3cf505</Value> <Threshold>-83</Threshold> <Value>#50f50a</Value> <Threshold>-1</Threshold> <Value>#64f014</Value> <Threshold>0</Threshold> <Value>#7deb32</Value> <Threshold>30</Threshold> <Value>#78c818</Value> <Threshold>105</Threshold> <Value>#38840c</Value> <<Threshold>300</Threshold> <Value>#2c4b04</Value> <Threshold>400</Threshold> <Value>#ffff00</Value> <Threshold>700</Threshold> <Value>#dcdc00</Value> <<Threshold>1200</Threshold> <Value>#b47800</Value> <Threshold>1400</Threshold> <<Value>#c85000</Value> <Threshold>1600</Threshold> <Value>#be4100</Value> <Threshold>2000</Threshold> <Value>#963000</Value> <Threshold>3000</Threshold> <Value>#3c0200</Value> <Threshold>5000</Threshold> <Value>#ffffff</Value> <Threshold>13000</Threshold> <Value>#ffffff</Value> </Categorize> </ColorMap> <ShadedRelief/> </RasterSymbolizer>
For additional information, please refer to OpenGIS® Symbology Encoding Implementation Specification.