The addition of WMS 1.3.

Justin Deoliveira

TBD

Under Discussion, In Progress, Completed, Rejected, Deferred

1.3 is the latest version of the WMS specification. It is also being mandated by the INSPIRE initiative that participating agencies provide map services with WMS 1.3.

Available on github.

In general the WMS 1.3 protocol does not change much protocol wise so implementing the new version is actually done with minimal effort compared to implementing new versions of other services such as WCS 1.1 and WFS 1.1.

One thing that does change with WMS 1.3 is the axis order of geographic coordinate systems. The specification mandates that the ordering of a geographic crs represented via an epsg identifier (for example EPSG:4326) be ordered latitude/longitude or y/x. This essentially “flips” the regular representation which is longitude/latitude or x/y.

Because of the way geoserver internally configures the geotools referencing subsystems, all geographic crs referenced by the historical epsg identifier, EPSG:XXXX, be ordered longitude/latitude. However there is an alternate and explicit notation in which the prefix urn:x-ogc:def:crs:EPSG:XXXX is used. When this prefixed is used it is interpreted to mean latitude/longitude.

So the approach to solving the axis order issue is simple. For WMS 1.3 operations simply replace the former prefix with the latter prefix during the request parsing phase of the operation.

A WMS 1.3 server may optionally implement the corresponding new version of the SLD 1.1. In SLD 1.1 the symbology component has been factored out into a separate specification known as Symbology Encoding. The funding for the initial WMS 1.3 work has allowed for an initial and partial implementation of SLD 1.1 and SE 1.1.

A full implementation of SE is not possible at this time because it allows for rendering constructs that geotools does not yet support at this time. So the approach is to implement all the parts of SE 1.1 that we are capable of supporting and in the future implement the remaining parts as funding becomes available for the missing constructs.

A list of the constructs we do not support at this time:

• well known functions such as classification, recoding, string, number, and date formatting
• perpendicular offset
• color replacement and inline content for external graphics
• mark index
• line generalization and gap support
• raster symbolizer changes

There are more, and will be researched and implemented when there are interested parties.

Most of the work to support SLD 1.1/SE 1.1 involves implementing a parser and an encoder at the geotools level. The parser/encoder will be gtxml based.

The rest of the work involves modifying the geoserver WMS module to allow for the two versions of SLD. At this time all of the operations assume SLD 1.0. Changing this will require the following changes.

The GetMap operation allows a user to specify a style directly via the SLD and SLDBODY parameters. The SLDVERSION parameter has been added which allows the user to specify which version of SLD is being used. Also the SLD schema requires the root StyledLayerDescriptor element to specify the version with a version attribute.

The approach is to change the GetMap operation to recognize the version of SLD being specified and use the appropriate parser. In cases where the SLD_VERSION parameter is not specified the parser must be smart in that it must “preparse” the style content to determine what the version is. Similar to how the ows dispatcher preparses content during a POST request in order to determine the service,request, and version of the operation being requested.

The OWS dispatching framework already supports the notion of choosing the appropriate parser / xml reader depending on the content of a POST request. So supporting GetMap POST for WMS 1.3/SLD 1.1 will involve implementing a new GetMapXmlRequestReader.

Similar to the GetMap operation, the PutStyles/GetStyles operations will have to choose the appropriate SLD parser/encoder depending on the content specified by the client.

The current StyleInfo configuration object also assumes the underlying style is encoded as SLD 1.0. In order to support multiple SLD versions a new property, sldVersion must be added to the interface.

interface StyleInfo {

   ...
   Version getSLDVersion();

   void setSLDVersion(Version version);
   ...
}

This attribute will be used by all code (currently living the ResourcePool class) do determine which SLD parser/encoder to invoke when attempting to serialize/deserialize a style object.

The approach to support the parsing/encoding/validation of different SLD versions is to implement a utility class. The current version of which can be found here.

The WMS capabilities document (and actually other operations) support the notion of extended capabilities. That is the capabilities documented is augmented with additional metadata and information about that particular WMS service. Initiatives such as INSPIRE make use of this capability.

The approach is to add a new extension point that allows plugins to contribute to the capabilities document. The extension point is called ExtendedCapabilitiesProvider. The current interface can be found here.

The current implementation passes all cite tests except for the tests having to do with time and elevation which are features not yet implemented at this time.

In the WMS 1.3 GetFeatureInfo operation the X/Y parameters have been replaced with I/J. However in testing out multiple WMS 1.3 client implementations it is commonly found that most clients still use X/Y for the parameters.

So as a compromise to support technically non compliant clients the GetFeatureINfo operation will support X/Y when I/J parameters are not present only when not running in strict cite compliance mode. In that case the client will receive a service exception.

Note that there has been work completed in conjunction with this work that is outside of scope for this proposal. In particular this proposal focuses on WMS 1.3 and getting the code base ready to handle SLD and SE 1.1. Outside of scope of this proposal is INSPIRE specific tasks, which will be put in a community module. These include handling of language parameter and inspire specific extensions to the GetCapabilities document. These do not need to get in to core, though may advance to extension at some point. But they are outside of the scope of this proposal.

This section should contain feedback provided by PSC members who may have a problem with the proposal.

The only compatibility issues are those of the change of axis order with the wms protocol. So clients accessing geoserver through wms 1.3 will need to be aware of the axis reordering for geographic coordinate systems.

Andrea Aime: +1 Alessio Fabiani: +1 Simone Giannecchini: +0 Ben Caradoc Davies: +1 Jody Garnett: +1 Mark Leslie: Rob Atkinson: Justin Deoliveira: +1 Gabriel Roldan: +1

JIRA Task Email Discussion Wiki Page