i. Abstract

This document proposes a set of best practices and guidelines for implementing and using the Open Geospatial Consortium (OGC) Web Map Service (WMS) to serve maps which are members of an ensemble of maps, each of which is a valid possible alternative for the same time and location. In the meteorological and oceanographic communities, it is Best Practice to produce a large number of simultaneous forecasts, whether for a short range of hours, a few days, seasonal or climatological predictions. These ensembles of forecasts indicate the probability distributions of specific outcomes. This document describes how to unambiguously specify an individual member of an ensemble, or one of a limited set of map products derived from a full ensemble.

In particular, clarifications and restrictions on the use of WMS are defined to allow unambiguous and safe interoperability between clients and servers, in the context of expert meteorological and oceanographic usage and non-expert usage in other communities. This Best Practice document applies specifically to WMS version 1.3, but many of the concepts and recommendations will be applicable to other versions of WMS or to other OGC services, such as the Web Coverage Service.

ii.          Keywords

The following are keywords to be used by search engines and document catalogues:

meteorology, oceanography, ensemble, member, time, elevation, time-dependent, elevation-dependent, wms, web map service 1.3, 1.3.0, ogc, best practice, ogcdoc

iii.          Preface

This Best Practice document is the result of discussions within the Meteorology and Oceanography Domain Working Group (MetOcean DWG) of the Technical Committee (TC) of the Open Geospatial Consortium (OGC) regarding the use of the OGC Web Map Service (WMS) to provide map visualizations from the various types of data regularly produced, analyzed, and shared by those communities. The discussion considered the differences in the types of data as well as the issues, concerns, and responsibilities of data producers when sharing those data as maps with end users, including analysts within the meteorological and oceanographic communities, users with specific needs and the general public. The limited scope of the requirements and recommendations in this document reflects the consensus reached by groups with vastly different types of data, limitations in the current design of the WMS specification, and compromises to ensure these services remain applicable to a mass market audience. Future work includes extending this Best Practice once the community gains more experience with implementing the provisions of this document. This document does not require any changes to other OGC specifications, but it is hoped that the WMS specification will evolve to address issues encountered in this work such as providing a mechanism to define exclusive dimensions and to define sparse combinations of dimensions.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation when possible.

iv.          Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium Inc.

• Deutscher Wetterdienst, Germany
• ECWMF
• KNMI, Ministry of Infrastructure and the Environment, Netherlands
• Météo-France
• Meteorological Service of Canada, Environment and Climate Change Canada
• UK Met Office
• US Air Force Directorate of Weather

v.          Submitters

All questions regarding this submission should be directed to the editors or the submitters:

1.             Introduction

The meteorological and oceanographic communities have been exchanging information internationally for at least 150 years and well understand the importance of geospatial standards for interoperability. These standards have typically defined data formats, interfaces, processes, shared conceptual models, and sustainable maintenance processes.

Because of the demanding nature of meteorological and oceanographic data processing, the communities have evolved domain specific solutions. However, as computers have become more powerful, it has become feasible to use general geospatial software for day-to-day operational purposes, and interoperability problems have arisen. There has also been an increasing need to combine meteorological and oceanographic data with other forms of geospatial data from other domains, in ways convenient for those domains.

Meteorological and oceanographic data are inherently multidimensional, not just in time and space but also over other dimensions, such as probability. In the meteorological and oceanographic communities, it is best practice to produce a number of simultaneous forecasts, whether for a short range of hours, a few days, a season or climatological predictions for a century. These ensembles of forecasts give an indication of the probability of specific outcomes.

This document describes and justifies a set of best practices for offering and requesting maps representing meteorological and oceanographic data selected from an ensemble of possibilities through WMS. This set of best practices is intended to meet the interoperability requirements of the meteorological and oceanographic communities and enable them and their customers to gain the economic benefits of using commercial, off the shelf, software implementations of WMS servers and clients.

1.1           Ensemble Forecast

Ensemble forecasts are the output of a numerical weather prediction system that facilitates the estimation of uncertainty in a weather forecast as well as the most likely outcome.

Instead of running the prediction once (a deterministic forecast), many predictions are computed, where each prediction uses slightly different input conditions. The result is called an ensemble forecast.

An ensemble forecast is a set of forecasts for the same times and locations. They are based on a set of equally likely scenarios, produced e.g. by perturbing the initial state, modifying the simulated physics, equation approximations, or boundary conditions. Any convergent or divergent distribution of the resulting set of forecasts can give an indication of the likelihood of the forecasts. Ensemble forecasts are not exact evolutions of a Probability Distribution Function for the atmosphere or oceans, as calculating these is currently an intractable problem.

When more ensemble forecasts are made, rather than fewer, the ensemble of possible outcomes is more likely to capture the most likely and the most extreme possibilities.

Generally, ensembles of about 10 forecasts are not enough, but 100 forecasts are more than ample to capture a practical range of possible outcomes.

There is also real value in combining ensembles, for the same times and locations, from different forecasting organizations, to produce a larger, multi-sourced ensemble which has improved skill compared to smaller, single-sourced, ensembles or even a similarly sized, single-sourced ensemble.

The production system is usually known as an EPS, Ensemble Prediction System.

1.2           Ensemble Member

The individual forecasts that comprise an ensemble are referred to as ensemble members. A forecasting service may select one member of an ensemble as the most appropriate prediction to offer to a customer (see Figure 1). Such a selection may be automatic or manual. A different organization’s ensemble may even be used, for example, as a back-up. Consequently, there is a need to identify a complete ensemble, a specific member, and the source or sources of that ensemble.

Contrast:

As all the ensemble members are, a priori, equally likely, there is no simple, easy to calculate, concept of two members being ‘near’ or ‘far’ from each other, or any one being the ‘most likely’.

1.3           Ensemble Product

This section describes the most common ensemble products and it briefly explains how they may be used. In general, two different types of ensemble products can be distinguished. One type delivers a chart that visualizes the data of all members. In the following, this type is called an all-member map. The other type produces new data as the result of a production process which takes all members as input. Some examples of this product type are aggregation maps, quantile maps or probability maps.

1.3.1      All-member maps

So-called postage stamp maps and spaghetti maps are the two most common ways to give an overview of all members.

A postage stamp map is a set of small maps showing plots of each individual ensemble member (see Figure 1). This allows the forecaster to view the scenarios in each member forecast and assess the possible risks of extreme events. However, this presents a large amount of information that can be difficult to comprehend.

A spaghetti map is a chart showing the contours of one or more variables from all ensemble members. This can provide a useful image of the predictability of the field. Where all ensemble member contours lie close together the predictability is higher; where they look like spaghetti on a plate, there is less predictability.

Consider for example Figure 2 and Figure 3. The graph in Figure 2 shows a 10-day temperature forecast for Brussels. There is confidence that it will become warmer for 4 or 5 days, and then probably cool, but the amount of cooling is less certain.

Figure 3 below shows a ‘spaghetti map’ of a North Atlantic, four day forecast of the ‘thickness’ of the lower atmosphere. Thickness is a measure of how warm or cold a layer of the atmosphere is. Usually a layer in the lower troposphere is chosen, between pressures of 1000 hPa and 500 hPa. The thickness is the difference in the heights of these two pressure levels, usually measured in decameters (Dm). A thicker layer is warmer than a ‘thinner’ layer. Thus, thickness acts as a proxy for the average temperature of the layer of atmosphere.

For example, a 1000-500hPa thickness of 528 Dm is relatively cold and indicative of snow rather than rain at sea level in Western Europe. The ensemble members, shown in the map of Figure 3, all consistently forecast this. But the forecasts of the warmer areas, indicated by a thickness of 564 Dm, are less certain.

Source:  UK Met Office using data from ECMWF, © UK Crown Copyright

Trajectory data present another example of meteorological data that often have multiple possibilities. A trajectory is the path that a moving object follows through space as a function of time. Trajectories are well recognized as often being very sensitive to the starting conditions, thus producing an ensemble of possible tracks is eminently sensible.

The distribution of possible trajectories can be shown by displaying all of them, or perhaps the extremes cases and an ‘average’ or ‘most likely’ track, though objectively defining what these are is a research topic and dependent on the detailed use case (see [Cheung 2014]).

Trajectories can run forward or backward. Good examples of forward trajectories are those for volcanic ash. They are usually calculated using the data of a numerical weather forecast. Such a forward trajectory predicts the movement of air masses from a given geographical position, in this case the location of the volcano. The trajectory has the same temporal and probabilistic associations as the numerical weather forecast because it is based on these data. An example of a backward trajectory is to find the upwind source of a nuclear pollution observation.

Figure 4 below shows two ensembles of forecasts for the tracks of two hurricanes, not unlike trajectories. A particular track could be chosen as the most likely. However, an ‘envelope’ of all possible forecast tracks could be constructed to be displayed with the most likely track, as in Figure 5.

1.3.2      Aggregation maps

Rather than pick a specific ensemble member or plotting all members in a spaghetti map, the complete ensemble forecast may be processed to produce statistics on the ensemble data. A typical statistical analysis is aggregation, such as the mean or standard deviation.

The ensemble mean is the average of the parameter value at each underlying data point over all ensemble members. The ensemble mean normally verifies better than the control forecast by most standard verification scores (root mean squared error, mean absolute error, temporal anomaly correlation coefficient, etc.) because it smooths out unpredictable detail and simply presents the more predictable elements of the forecast. It can provide a good guide to the element of the forecast that can be predicted with confidence, but should not be relied on its own, as it will rarely capture the risk of extreme events.

The ensemble spread is calculated as the (non-biased) standard deviation of an ensemble forecast. It provides a measure of the level of uncertainty in a parameter in the forecast. It is often plotted on charts overlaid with the ensemble mean. Figure 6 shows both the ensemble mean of pressure at mean sea level as blue contours and spread of Mean Sea Level Pressure as color shading. The areas of strong colors indicate larger spread and therefore lower predictability.

1.3.3      Probability maps

A customer may require a probabilistic forecast service, rather than a deterministic one. For example:

“The probability that the surface temperature overnight at location (x,y) will fall below 4°C is 85%”

would be preferred to:

“The minimum temperature overnight at location (x,y) will be 2°C.”

The latter forecast, even though described deterministically, is in fact probabilistic, but the statistics can only be determined after that event, and many similar events. Informed customers may have an expectation of the accuracy of these verified forecasts.

Ensembles allow an estimation of the probability that an event occurs at a particular location or grid point. Figure 7 shows the probability of wind gusts exceeding 40 knots. There is a very high probability in the North Atlantic between Scotland and Iceland. The ensemble mean of Mean Sea Level Pressure is also included as grey contours.

1.3.4      Quantile maps

A set of quantiles of the ensemble distribution can provide a short summary of the uncertainty. Commonly used quantiles are quartiles. The first quartile, also called the lower quartile or the 25 percent quantile, separates the lowest 25% of data from the highest 75%. The second quartile, also called the median or the 50 percent quantile, divides the data set into two halves. The third quartile, also called the upper quartile or the 75 percent quantile, separates the highest 25% of data from the lowest 75%. Another set of quantiles which is often used includes the 5%, 10%, 90% and 95% percentiles.

1.3.5      Further statistic maps

Many more products can be derived from ensembles using statistical functions. Ensemble data can be used to make a trend analysis or to test the significance of a trend. Other statistical evaluations of an ensemble are the minimum, maximum and median values. The median is the mid-point value where half of the values are above and half below.

1.3.6      Site-specific meteograms

Forecast output variables can be extracted from the grid for specific locations. There are many presentations that can be used to represent the forecast at locations, such as plume charts and probability of precipitation. One of the most commonly used is the ensemble meteogram which uses a box and whisker plot to illustrate the main percentile points of the forecast distribution for one or more variables (see Figure 8).

Source: UK Met Office, © UK Crown Copyright

2.             Scope

This version of this Best Practice document intentionally addresses a limited number of issues related to the use of WMS for ensembles of data in order to produce an initial document as a basis for future development. The document considers the issues with some of the most common ensemble derived data.

The document describes how to offer WMS layers for:

1. No dependency on ensembles;
2. An ensemble forecast, i.e. a complete set of ensemble members for a given area and time;
3. A single ensemble member of an ensemble forecast for a given area and time; and
4. The following list of ensemble products:
   • Ensemble Mean;
   • Ensemble Spread (Standard Deviation);
   • Ensemble Minimum;
   • Ensemble Maximum;
   • Ensemble Median;
   • First Quartile (25% quantile); and
   • Third Quartile (75% quantile).

The document also specifies constraints on the behavior of WMS clients that have been created specifically to use WMS implementations that follow the requirements of this document. This document specifies a constrained, consistent interpretation of the WMS 1.3 standard that is applicable to government, academic, or commercial providers or users of ensemble data offered as a WMS product.

This version of this Best Practice document has left many issues out of its scope. Design issues with WMS such as related to offering a large number of layers or offering data that are updated frequently were not directly tackled. Issues in the workflow of users relying of a distributed spatial data infrastructure such as the discovery of services, or directly of layers, were not considered.

Rules for specifying Time and Elevation unambiguously are addressed elsewhere, but should be able to be used simultaneously with this specification.

Rules for the use of data using climatological periods, climatological ranges and non-Gregorian calendars proved too complex for this version. No work was done to address issues related to expressing the semantic content of particular layers. Developing a mechanism to obtain visualizations of non-horizontal data such as vertical slices was considered too but rejected as this would require modification of the design of WMS itself.

3.             References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC: OGC 06-042 - OpenGIS Web Map Server Implementation Specification, Version 1.3.0, 2006.
http://portal.opengeospatial.org/files/?artifact_id=14416 .

OGC: OGC 11-111r1 - OGC Best Practice for using Web Map Services (WMS) with Time-Dependent or Elevation-Dependent Data, Version 1.0, 2014.
https://portal.opengeospatial.org/files/?artifact_id=56394 .

WMO: WMO No. 306, Manual on Codes, World Meteorological Organization operational data formats, 2016.
http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/LatestVERSION/LatestVERSION.html .

WMO: WMO No. 1091, Guidelines on Ensemble Prediction Systems and Forecasting, 2012.
https://www.wmo.int/pages/prog/www/DPFS/Manual/EPS-Guidelines.html .

W3C: SOAP Version 1.2 Part 1: Messaging Framework (Second Editions), 2007.
https://www.w3.org/TR/soap12 .

IETF: RFC 7540, Hypertext Transfer Protocol, Version 2 (HTTP/2), 2015.
https://tools.ietf.org/html/rfc7540 .

4.             Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards.

In particular:

1. SHALL – verb form used to indicate a requirement to be strictly followed to conform to this document, from which no deviation is permitted.
2. SHOULD – verb form used to indicate desirable ability or use, without mentioning or excluding other possibilities.
3. MAY – verb form used to indicate an action permissible within the limits of this document.

For the purposes of this document, the following additional terms and definitions apply.

4.1          

Client

Software component that can invoke an operation from a server

4.2          

Control member or control forecast

A forecast of an ensemble that has been produced without any perturbations of the simulated physics or other approximations, boundaries or initial conditions.

4.3          

Ensemble

Set of parallel forecasts, all a priori equally likely, for the same times and locations. Often the simulated physics or initial conditions are slightly perturbed for each forecast.

4.4          

Feature

Abstraction of real world phenomena [ISO 19101:2002, definition 4.11]

4.5          

Geographic information

Information concerning phenomena implicitly or explicitly associated with a location on Earth [ISO 19101]

4.6          

Interface

Named set of operations that characterize the behaviour of an entity [ISO 19119]

4.7          

Layer

Basic unit of geographic information that may be requested as a map from a server

4.8          

Map

Portrayal of geographic information as a digital image file suitable for display on a computer screen

4.9          

Operation

Specification of a transformation or query that an object may be called to execute [ISO 19119]

4.10       

Portrayal

Presentation of information to humans [ISO 19117]

4.11       

Request

Invocation of an operation by a client

4.12       

Response

Result of an operation returned from a server to a client

4.13       

Server

A particular instance of a service

4.14       

Service

Distinct part of the functionality that is provided by an entity through interfaces [ISO 14252]

5.             Conventions

5.1           Abbreviated terms

CRS                 Coordinate Reference System

Dm                  decameter, i.e. 10 meters

EPS                 Ensemble Prediction System

HTTP             Hyper Text Transfer protocol

ISO                  International Standards Organisation

OGC               Open Geospatial Consortium

SOAP              Simple Object Access Protocol

UTC                Universal Coordinated Time

WMO             World Meteorological Organization

WMS              Web Map Service

XML               eXtensible Mark-up Language

5.2           Notational conventions

This sub-clause provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

WMS 1.3 states that request parameter names shall not be case sensitive, but parameter values shall be.

Any keywords from the WMS Standard are depicted in Courier font, lower case if the words refer to the dimension, UPPER case if it refers to the parameter of the GetMap request.

Any example values for keywords from the WMS Standard or this Best Practice document are depicted in lower case italic.

Further, in this Best Practice document we will use CamelCase or camelCase for entities. For defined classes, we use UpperCamelCase and for defined attributes, we use lowerCamelCase. For example, values, we use lower_case_under_score. For URIs, we use lower-case-with-hyphens, as this seems to be easier for humans, especially on mobile devices.

6.             Requirements

This document defines injunctions for the use of OGC Web Map Service implementations for the distribution of map visualizations based on data derived from an ensemble of possibilities. The injunctions constrain how such data offerings should be structured into WMS layers, the way such layers should be described in the WMS Capabilities document, the way requests for such layers should be handled, and the way clients should issue requests for such layers. These injunctions do not necessitate modifications to the WMS standard but merely define rules for the use of that standard.

The injunctions of this document target server and client implementations. “Conformant WMS servers” are WMS server implementations that follow the injunctions of this document to offer ensemble derived data as WMS layers. This document places restrictions on how these layers will be structured so that it will be useful to general purpose client software applications and to advanced client software applications specifically built for the needs of the community. “Conformant WMS clients” are WMS clients that are expected to provide a user interface to select dimensional values; this document places certain restrictions on these clients to reduce the chance of confusion or error.

The WMS 1.3 standard defines a system for declaring and requesting map layers with more dimensions than the two spatial dimensions represented in the map visualization. The standard defines a mechanism to assign dimensions to a map layer in the Capabilities document and then defines a specific dimension, ensemble. A WMS Layer is declared to be available at one or more values in a dimension by declaring an XML <Dimension> element either in the <Layer> element itself or in a parent layer, in which case the dimension will be inherited.

For example, a Capabilities document might contain:

<Layer>
 
…<Dimension name=”ensemble_member” units=”” unitSymbol=””
              nearestValue=”0” multipleValues=”1”>1/40/1</Dimension>
   <Layer>
       <Name>Surface_Irradiance</Name>
       …
   </Layer>
   <Layer>
       <Name>Temperature</Name>
       …
       <Dimension name=”elevation” units=”computed_surface” unitSymbol=””
                  default=”surface” multipleValues=”0” nearestValue=”0”
                  >surface,tropopause</Dimension>
                 
   </Layer>
 
</Layer>

where the outer layer defines an ensemble dimension which is inherited by both inner layers and the inner layer Temperature also declares that it is available at two heights. The ensemble dimension is declared with a <Dimension name=”ensemble_member” …> element and the corresponding GetMap request may include the condition DIM_ENSEMBLE_MEMBER=m with an appropriate value m.

Further dimensions can be declared with a <Dimension name=”somename” …> element and the corresponding GetMap request may include the condition DIM_SOMENAME=v with the parameter name DIM_SOMENAME and an appropriate value v. WMS has already defined TIME and ELEVATION as possible dimensions.

While the mechanism defined by WMS 1.3 is powerful, it unfortunately also has limitations. The mechanism does not provide any way to declare that dimensions are exclusive of one another. The mechanism does not provide any alternate way to declare what combinations of values in the different dimensions are available, making the discovery of available combinations a guessing game for the client.

Another limitation is that the WMS 1.3 protocol does not provide a general mechanism to return supplemental information for a request. However, the need for such a mechanism is widespread, especially for the handling of multi-dimensional layers. Consider for example a GetMap request with no value for a dimension of the requested layer. The WMS server shall use the default value in such a case, but the issuer of the request will not know the value that was actually used in preparing the response. Chapter C.4.2 of the WMS 1.3 specification addresses this issue and proposes the use of the HTTP response header for a transmission of the default value.

A second example is the applicability of dimension values in GetMap requests for multiple layers. Chapter C.3.5 of the WMS 1.3 specification considers this case and requires conformant WMS servers to apply a dimension value that is given in a GetMap request only to those layers that have that dimension. The value is ignored for all other layers. Hence, a map is returned and the issuer of the request will not know the layers to which the dimension value has been applied. A solution, similar to the one described in chapter C.4.2, could be the use of the HTTP response header.

The solution with the HTTP response header has several drawbacks, however. It is only available to clients aware of its presence and able to get the header, and the solution only works when the WMS messaging is directly embedded in the HTTP header rather than, say, embedded in XML (i.e. SOAP). The solution is also unreliable as a source of error prevention because the absence of the header does not indicate anything since the request may have been satisfactory.

The need for supplemental information for GetMap requests is one of the motivations for the development of WMS 2. This Best Practice document will therefore neither make requirements nor recommendations how this problem should be handled. It seems better to wait for the solution developed in WMS 2.

This clause specifies requirements and recommendations for the use of a new dimension named ensemble. This specification considers only the OGC standard:

OpenGIS® Web Map Server Implementation Specification, version 1.3.0 (OGC 06-042)

which is the only version of the standard that has not been deprecated at the time of writing of this Best Practice document.

6.1           Ensemble Independent Data

Data providers may wish to offer WMS layers that have no ensemble dependency. In this case, the following requirement applies:

6.2           Ensemble Forecast

Data providers may wish to offer data that has a dependency on ensemble forecasts. In this case, the following requirements apply to a WMS server.

This Best Practice document recommends the use of a dimension called ENSEMBLE_MEMBER if the domain values of this dimension can be restricted to a list of consecutive member numbers, starting at 0 or 1. Values for this dimension can be specified in client requests using the DIM_ENSEMBLE_MEMBER element. As a client request sets a unique value for the DIM_ENSEMBLE_MEMBER, a single request cannot be used to request multiple layers that implement different semantics.

The dimension ENSEMBLE_MEMBER shall be used in accordance with the following guidelines.

Conformant WMS servers can handle GetMap requests for an ensemble forecast layer according to the decision tree shown in Figure 9.

6.3           ENSEMBLE Members

Data consumers may wish to get maps from one or several ensemble members. In this case, the following requirements apply to a WMS client.

6.4           ENSEMBLE Products

Data providers may wish to offer maps for ensemble derived products. This Best Practice is limited to a short list of ensemble derived products that do not need supplied parameters for their derivation, such as threshold values. This restriction is because the WMS 1.3 specification does not have a concept of user-defined GetMap request parameters besides the definition of other sample dimensions (see Table 8 of the WMS 1.3. specification).

General probability or quantile maps are parameterized ensemble derived products. The user has to provide a condition for the probability map (“temperature will fall below 4°C”) or a percentage value for the quantile map. These values cannot be put into a GetMap request and passed to a conformant WMS 1.3 server without extending the current WMS specification.

In general, for the provision of non-parameterized ensemble derived products the following requirements apply to a WMS server.

  <Layer>
     <Name>EPS-T2M-LAYERS</Name>
     <Title>layer for the 2m temperature
  ensemble forecast and according product layers</Title>
     <Layer queryable=”1”>
        <Name>EPS-T2M</Name>
            …
        <Dimension name=”ensemble_member”
  units=””unitSymbol=”” nearestValue=”0” multipleValues=”1”>1/20/1</Dimension>
            …
     </Layer>
     <Layer queryable=”1”>
        <Name>MEAN-T2M</Name>
          …
     </Layer>
     <Layer queryable=”1”>
        <Name>SPREAD-T2M</Name>
          …
     </Layer>
  </Layer>