This page last changed on Dec 20, 2010 by bmmpxf.

Discussion of the implementation of WMS 1.3.

Protocol

Protocol wise WMS 1.3 does not bring much besides some parameter name changes for some of the operations. In terms of implementation it should be easy to integrate WMS 1.3 into the existing wms module. This in contrasts to for example WCS 1.1, where the spec was drastically different and required a new module and service.

The current implementation is being worked on in a github branch.

Axis Order

WMS 1.3 defines geographic coordinate systems specified with an EPSG identifier to have a "flipped" axis order of latitude/longitude or x/y. This is similar to WFS 1.1 in which the urn:x-ogc:def:crs:EPSG: namespace also defines axis order as latitude/longitude.

It is planned to take work that was done as part of WFS 1.1 to support the flipped EPSG axis representation.

SLD 1.1 / Symbology Encoding 1.1

WMS 1.3 servers have the option of implementing a new version of SLD, and a new SE spec which is really just the portrayal stuff taken out of SLD and thrown into its own specification. This is in addition to supporting existing SLD 1.0. So whether or not we want to tackle an initial SE implementation is on the table, but not required to implemented WMS 1.3.

SE 1.1 brings a new syntax for styling and a number of new rendering constructs. Some of the new constructs such as uom support have already been implemented. Some of the other notable features that are not yet implemented include:

  • 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
  • TODO: fill in more of these

Past support for the actual rendering of these new symbology constructs the geotools styling object model will need to be expanded on, much of which appears to have already been done.

And finally a parser/encoder is needed to serialize/deserialize SE instance documents.

Given that support for symbology encoding in geotools not quite complete at this point a possible approach is to focus on parsing/encoding/representing those constructs that geotools does implement. And as new features are added migrate the parsers/encoders accordingly.

GeoServer StyleInfo

GeoServer currently only supports a single styling language, SLD 1.0. With SLD 1.1 and SE 1.1 users now have an option of what language to use to define a new style. To support this the existing StyleInfo class will need to be extended to add some additional metadata about what language and version the actual style is represented as.

This will also undoubtedly require an interface or an extension point that will be used to serialize, deserialize, and validate a particular representation of a style. An extension point also would have the benefit of allowing for non SLD based style languages. Most pertinent being the css like format being developed currently as a geoserver community module.

A rough cut of these interfaces might look something like:

interface StyleInfo {
   
   enum Type {
     SLD, SE, CSS
   };


   Type getType();
}
interface StyleHandler {

  boolean canHandle(StyleInfo style);

  Style parse(StyleInfo style, InputStream in) throws IOException;

  void encode(StyleInfo style, Style style, OutputStream out) throws IOException;
}

Extended Capabilities / INSPIRE

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

A possible design in support of this is to allow plugins to contribute to the capabilities document via an extension point. A possible extension point, let's call it ExtendedCapabilitiesProvider, might look something like:

interface ExtendedCapabilitiesProvider {

  /** return location of schema that defines the structure of the extended caps */
  String getSchemaLocation();

  /** register any relevant namespace prefix mappings */
  void registerNamespaces(NamespaceSupport);

  /** encode the extended capabilities */
  void encode(Translator tx);
}

Timeline

The intention is to get WMS 1.3 into the 2.1 somewhere. Possibly 2.1.0 depending on when it is released, but most likely some later release such as 2.1.1 or 2.1.2.

Update: WMS 1.3 was added to GeoServer as of version 2.1-beta3.

Document generated by Confluence on May 14, 2014 23:00