OpenGIS Styled Layer Descriptor (SLD) Implementation Specification
OGC Announces Styled Layer Descriptor and Symbol Encoding Specifications
Wayland, MA, USA. August 15, 2007.
The members of the Open Geospatial Consortium, Inc. (OGC) have approved the OpenGIS Styled Layer Descriptor (SLD) Implementation Specification (a profile of the Web Map Service) and the related OpenGIS Symbology Encoding Implementation Specification.
The OpenGIS Styled Layer Descriptor (SLD) profile of the Web Map Service Implementation Specification defines an encoding that extends the Web Map Service specification to allow user-defined symbolization of feature and coverage data. It allows users to determine which features or layers are rendered with which colors or symbols.
SLD addresses the important need for users (and software) to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. Symbology Encoding provides this language, while the SLD profile of WMS enables application of Symbology Encoding to WMS layers using extensions of WMS operations. Additionally, SLD defines an operation for standardized access to legend symbols.
The OpenGIS Symbology Encoding Implementation Specification defines Symbology Encoding, an XML language for styling information that can be applied to digital Feature and Coverage data.
The OpenGIS Styled Layer Descriptor (SLD) profile of the Web Map Service is, together with the OpenGIS Symbology Encoding Implementation Specification, the direct follow-up of Styled Layer Descriptor Implementation Specification 1.0.0. The old specification document was split into two documents to allow parts that are not specific to WMS to be reused by other service specifications. Symbology Encoding is independent of any service descriptions and could therefore also be used to describe styling information of systems not connected to any kind of service (e.g., desktop geographic information systems), while the SLD profile of WMS describes how Symbology Encoding can be applied to WMS layers.
The OGC is an international industry consortium of more than 340 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available interface specifications. OpenGIS Specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. The specifications empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications. Visit the OGC website at http://www.opengeospatial.org.
Executive Director, Outreach and Community Adoption
Open Geospatial Consortium, Inc.
35 Main Street, Suite 5, Wayland, MA 01778 USA
... "Finally, there is the application layer. The application layer is interesting in that the standards that exist at this level can be quite simple, such as GeoRSS, or quite sophisticated and semantically expressive, such as the OGC Styled Layer Descriptor standard. As with the other layers, there are other geospatial standards being developed for this level that are not OGC standards. For example the presence architecture developed in the IETF Instant Messaging and Presence Protocol (IMPP) working group has defined a format for presence information called Presence Information Data Format (PIDF). PIDF is an XML format that provides presence information about a "presentity". An extension to PIDF has been defined with a Presence based Geopriv Location Object Format (PIDF-LO). PIDF-LO carries either civic, geospatial location information or both. PIDF-LO is a GML application schema. As such, PIDF-LO itself is a relatively simple standard but one that is grounded in a very rich and expressive standard — GML. And GML is grounded in the ISO Feature model. So, in the application layer, a common characteristic is that relatively simple standards can be developed and deployed that are profiles or application schemas of other, more "complex" standards such as GML.
OGC standards play an important role in all levels. This does not mean that the OGC is developing standards for all levels and all application areas. Instead, many other standards organizations, such as the IETF, IEEE, OMA, and OASIS are building on the work of the OGC to define profiles and application schemas for their specific requirements. Many of these profiles and schemas, such as those used in GeoRSS and IEEE 1451, are simple and lightweight. Each meets a specific requirement..."
Styled Layer Descriptor Profile of the Web Map Service Implementation Specification. Edited by Dr. Markus Lupp. Open Geospatial Consortium Inc. Date: 2007-06-29 Reference number of this OGC document: OGC 05-078r4 Version: 1.1.0 (revision 4) Category: OGC Implementation Specification. Annex B presents normative XML schemas. Annex C (informative) suppplies example XML documents. [source]
This OGC Implementation Specification specifies how a Web Map Service can be extended to allow user-defined styling. Different modes for utilizing Symbology Encoding for this purpose are discussed.
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. From USGS' topographic map series to NOAA and NIMA's nautical charts to AAA's Triptik, fine-grained control of the graphical representation of data is a fundamental requirement for any professional mapping community.
The current OGC Web Map Service (WMS) specification supports the ability for an information provider to specify very basic styling options by advertising a preset collection of visual portrayals for each available data set. However, while a WMS currently can provide the user with a choice of style options, the WMS can only tell the user the name of each style. It cannot tell the user what portrayal will look like on the map. More importantly, the user has no way of defining their own styling rules.
The ability for a human or machine client to define these rules requires a styling language that the client and server can both understand. Defining this language, called the Symbology Encoding (SE) is done in a companion document of this specification. This language can be used to portray the output of Web Map Servers, Web Feature Servers and Web Coverage Servers. This document defines how Symbology Encoding can be used in conjunction with Web Map Services. In many cases, however, the client needs some information about the data residing on the remote server before he, she or it can make a sensible request. This led to the definition of new operations for the OGC services (see Clauses 8 and 9) in addition to the definition of the styling language.
There are two basic ways to style a data set. The simplest one is to color all features the same way. For example, one can imagine a layer advertised by a WMS as 'hydrography' consisting of lines (rivers and streams) and polygons (lakes, ponds, oceans, etc.). A user might want to tell the server to color the insides of all polygons in a light blue, and color the boundaries of all polygons and all lines in a darker blue. This type of styling requires no knowledge of the attributes or 'feature types' of the underlying data, only a language with which to describe these styles. This requirement is addressed by the FeatureTypeStyle element in the SE document.
A more complicated requirement is to style features of the data differently depending on some attribute. For example, in a roads data set, style highways with a three-pixel red line; style four-lane roads in a two-pixel black line; and style two-lane roads in a one-pixel black line. Accomplishing this requires the user to be able to find out what attribute of the data set represents the road type. SLD profile of WMS defines the operation that fulfils this need, called DescribeLayer. This operation returns the feature types of the layer or layers specified in the request, and the attributes can be discovered with the DescribeFeatureType operation of a WFS interface or the DescribeCoverageType of a WCS interface..."