Serving extra metadata about WMS Layers and map

Introduction

Many projects have a requirement to be able to serve metadata through a WMS that is not encoded in a standard Capabilities document. Motivated by the immediate needs of the MyOcean project, a short discussion was held on the Met Domain WG mailing list to discuss alternatives.

Requirements

The particular needs of the MyOcean project are to serve metadata that is needed to support its INSPIRE-compliant View Service. The View service will display the results of ocean model forecasts and analyses, i.e. gridded data. (Future versions of the View service will encompass in-situ and maybe along-track datasets.) Each variable in an ocean model is modelled in WMS as a displayable Layer (i.e. a Layer with a Name element).

There are two classes of requirements: the need to serve extra metadata about a particular Layer, and the need to serve metadata about a particular map image, i.e. the result of a WMS GetMap invocation.

Serving extra metadata about Layers

This kind of metadata includes the units of measure of the variable/Layer and a "sensible" minimum and maximum value for a colour scale.

Although the WMS 1.3 specification states that the MetadataUrl element is to be used for "standardized" metadata, the group felt that it was perfectly valid to use this for more informal metadata, provided that the metadata type was set to a project-specific string. ISO19115/139 may not be a good choice for this metadata in this case, but some XML format will be chosen for MyOcean.

• A modification to this, suggested by Lucian Plesea of JPL NASA, is to use the field of the ISO19115/139 metadata, so the required metadata is at two levels of indirection from the Capabilities document. However, this would require no modifications to ISO19115/139, although we'd need to agree the type of any link.

Serving extra metadata about a particular map image

Sometimes clients need to know more information about a map image that can be transmitted in a PNG, JPEG or other "basic" image type. This information may include the min and max data values in the image. There are a number of alternatives:

1. Use a non-standard WMS operation (e.g. GetMapInfo), described in the ExtendedCapabilities section of the WMS Capabilities document.
   • Disadvantage: non-standard WMS operations require changes to clients (but any solution will need a "special" client anyway in order to interpret the metadata correctly).
   • Disadvantage: the underlying data could change in between invocations of getting the image and getting the metadata.
2. Use image types that can support metadata headers, e.g. GeoTIFF.
   • Disadvantage: not very "web-friendly" since web browsers cannot display GeoTIFFs without plugins.
3. Allow GetMap to return metadata (as XML) instead of an image.
   • Disadvantage: the underlying data could change in between invocations of getting the image and getting the metadata.
4. Use multipart return types, e.g. return a zip or KMZ file containing both the image and the metadata
   • Advantage: image and metadata guaranteed to be coherent
   • Disadvantage: not "web-friendly" since web browser clients (and Javascript) would not be able to decode the zip file and display the image easily.
5. Use HTTP headers in the response to return the information
   • Advantage: image and metadata guaranteed to be coherent
   • Advantage: precedent in OGC standards (see sections C.4.2 and C.4.3 of the WMS 1.3.0 spec, in which it is used to indicate that a default or nearest-neighbour value was used for a requested dimension value).
   • Advantage: parseable in web environments (via XmlHttpRequest calls)
   • Disadvantage: may be stripped out by proxy servers
   • Disadvantage: some clients (e.g. Adobe Flex) do not provide access to the response headers
6. Use a new Layer to store the metadata for a particular Layer
   • Disadvantage: doubles the number of layers on the server
   • Disadvantage: No way to semantically link a layer to its associated metadata layer.
7. Use GetFeatureInfo
   • Advantage: A GetFeatureInfo by default includes most of a GetMap request, so it is clear what the metadata request is for.
   • Disadvantage: May clash with existing uses of GFI
   • Disadvantage: Refers to a specific pixel in the image, not the image as a whole
   • Disadvantage: the underlying data could change in between invocations of getting the image and getting the metadata.

The consensus in the discussion was to allow GetMap to return XML. We note that data could change between invocations of GetMap (one to get the image, one to get the metadata). This may be a problem in certain applications.

(Outstanding question: on further reflection, I wonder if an HTTP header-based solution may be preferable since it maintains coherency and has precedent in OGC. UPDATE Maybe not, given that many client libraries, such as Flex, don't provide access to the headers.)

A note about coherency

(Suggestion from Jozef Matula:) one way to solve the coherency problem between consequent GetMap and some kind of GetMapMetadata requests is to send back with GetMap response only a "temporary metadata ticket" in the HTTP header, which can be used with GetMapMetadata to acquire metadata resulted from previous GetMap request. This introducec basically a semi-state mechanism, but it's easy to implement it on the server (you just need a temporary cache of tickets and bound metadata). Good point here is that if the metadata is large you don't have to send it to the client if he does not need it.

-- JonBlower - 24 May 2010