ISO 19117 specifies the interface and associated classes for a portrayal service. In true "abstract specification" form, this interface is so general it's really very hard to think about without having a concrete example to mull over. I think such an example can be found in WMS 1.3.0. The objective of performing such a thought experiment is to guide the implementation of a set of GeoAPI interfaces (and GeoTools implementation) for a generalized portrayal service.

A Note about WMS 1.3.0

One fairly major change in the release of WMS 1.3.0 is the omission of Styled Layer Descriptors. There is no longer a standard language whereby a client can specify exactly how it wants the map to look. All styles are defined internally to the server and referenced by name. Styles may not take parameters (like line width, or stroke pattern). Static styles are referenced by name in the URL of the GetMap request. The server is responsible for declaring (and naming) what styles are legal to use with what layers in the GetCapabilities request. The styles should be described in human readable format, but are not described in an automatically parsable format.

A basic WMS classifies its geographic information holdings into "Layers" and offers a finite number of predefined "Styles" in which to display those layers. This International Standard supports only named Layers and Styles, and does not include a mechanism for user-defined symbolization of feature data.

NOTE: The Open Geospatial Consortium (OGC) Styled Layer Descriptor (SLD) specification defines a mechanism for user-defined symbolization of feature data instead of named Layers and Styles. In brief, an SLD-enabled WMS retrieves feature data from a Web Feature Service and applies explicit styling information provided by the user in order to render a map.

This distinction is important to make at the outset because it significantly restricts the scope of what is expected of a WMS. At the same time, it adds power. Anything which the web server knows how to render, it can name. Wind barbs, for instance, while impossible to specify correctly with SLD, are just another named Style to a WMS. It is also important to note that this restriction (of predefined names) is not imposed by 19117. The restriction is an artifact of the implementation and nothing more.

To summarize: a WMS 1.3.0 has a server-dependant means of specifying both the sources of data (the Layers) and the means of portraying that data (the Styles). These quantities are completely under the control of the server and no means is specified for the clients to designate additional data or custom symbolization. Clients may only choose from a list of options supported and advertised by the server.

Definition of Terms

Basic Portrayal Service

The basic portrayal service interface as defined by ISO 19117 is very simple. Its one operation called "portrayFeature" takes two arguments: a list of feature instances to portray and a list of portrayal catalogues, which define how the feature is to be portrayed. This operation returns nothing and specifies nothing further.

Definition of terms

ISO 19117 defines five basic conceptual items required for the portrayal of data. These are:



Portrayal Catalogue

A portrayal catalogue class consists of a set of feature portrayal objects; many may exist for each feature type that may occur in the data set.

Feature Portrayal

PF_FeaturePortrayal object refers to a feature type through its feature name attribute. The feature type shall be defined in the feature catalogue and further specified in the application schema. For each feature class, there can be a number of portrayal rules.

Portrayal Rule

PF_PortrayalRule describes one particular portrayal rule. It has a name, textual description, a formal definition of rule statement and a portrayal action association. If the formal definition of the rule evaluates to TRUE, the corresponding portrayal action shall be invoked.

Portrayal specification (action)

PF_PortrayalSpecification holds the instances of the portrayal specification, one for each PF_PortrayalOperation.

Portrayal Operation

PF_PortrayalOperation holds the details for a particular portrayal operation. It declares a set of formal parameters that are needed when invoking the underlying rendering functions. It has associations to the formal parameter values for the operation.

There are a couple of contentious problems with the above definitions, but this serves to illustrate, in broad strokes, the toolset with which a portrayal service may be constructed. (The most glaring error in the above is that PF_FeaturePortrayal has no feature name attribute, but this is moot for this discussion.)

Mapping of 19117 to OGC WMS 1.3.0 Layers and Styles

The definitions in the previous section lead to the following mappings:

  1. A "layer" is a collection of one or more feature instances, not necessarily of the same type.
  2. A "style" is a portrayal catalogue, fully populated with one feature portrayal for every feature type contained in the associated layer.

Note: A style can be an "intelligent, scale sensitive" style; capable of different actions under different conditions. This is represented in the portrayal schema by the fact that a feature portrayal contains many portrayal rules, each of which controls a specific action if the ruleset matches the conditions.

WMS 1.3.0 as an implementation of 19117

How multiple layers are handled

The portrayal specification (19117) does not specify in what order (front to back) features should be rendered. OGC 1.3.0 does. The LAYERS parameter of the GetMap request is a comma separated list of layers. The first element in the list is drawn in the back, the next is drawn over the top of that, and so on.

How layers are associated with styles

Each GetMap request has a LAYERS and a STYLES parameter. Both are comma-separated lists of layers or styles, respectively. Both lists must have the same number of elements, and the lists are made to correspond by element position. For instance, the first element in the LAYERS list is symbolized by the first element in the STYLES list, and so on.

Which styles are legal to use with which layers?

The GetCapabilities request returns what is known as service metadata. Part of the service metadata is a collection of one or more <Layer/> elements which define what data are available. Each <Layer/> element includes one or more <Style/> elements which define the legal styles which may be applied to this layer.

What actions generate exceptions?

What constraints are placed on the portrayal?

ISO 19117 places no constraints on the allowed presentation of information. It specifically states that portrayal may include such things as audible cues or output from a tactile device (for the visually impaired). WMS 1.3.0 is geared toward producing one or more 2D raster images in a number of supported formats.