Time issues for meteorology and oceanography WMS

Introduction

Time in meteorological and oceanographic products is multidimensional. There are several type of data which can lead different use cases :

• Observations
• Forecasts
• Climatologies
• Context data (geographical mainly)

Forecast time

Forecasting products are defined by a bi temporal time : Validity time = Run base time + Forecast (=Time offset)

Multiple time range semantics

A period of reference is often necessary for products as average, minimum, maximum, accumulation, (for climatology or rain accumulations...), validity period (for Significant weather charts for instance)...

Get time and Time series

How to specify a list of times?

Time & GetCapabilities

It would be useful to include product instance availability information (ISO 19108) in GetCapabilities response :

No dedicated tags for TIME information in GetCapabilities response in WMS 1.1.1 and 1.3.0

Possible approaches

• Dimension?

• ExtendedCapabilities? ?

Discussions

-- TrondMichelsen - 27 Nov 2009

I have a suggestion for how to deal with our problem with complex dimension dependecies in the capabilities document.

The suggestion is a bit long, so I put it on a separate wikipage: MetTimeSuggestionTM

As requested, I have prepared a short description of my proposal for handling TIME in a Met-Ocean WMS. It's on a separate page: MetTimeOneCapabilitiesDocPerRun.

-- JonBlower - 14 Jan 2010

-- JozefMatula - 22 Jun 2009

Forecast time Forecasting products are used in 2 major use cases:

• User cares only about validity - this is for example the case if the client only demands the information from the "latest" NWP model run for a certain validity/verification time.
• User cares about Run - this is especially the case, if client is from meteorological domain, where certain weather analysis procedures imply accessing different model runs (for example comparing the same forecast time from 2 consequent NWP model runs).

In the first case, the validity time can be expressed by a single WMS TIME dimension, however in the seconds case more complicated approach is necessary. TODO - please move here all references to Run&Forecast access solutions (summary of various options from MetTopicsOfInterest , model time/run in the layer name from MetGetCapabilitiesLayering, etc...)

Note, using of WMS dimension typically reduces size of GetCapabilities? document comparing to putting particular dimension values (wave lengths, levels, ...) into layer name.

Known issues:

• Run and Forecast are "orthogonal" independent dimensions (if you imagine them as 2 mathematical sets, then theoretically every Run&Forecast pair is allowed, however Run and Time are dependent and they for a "skewed" space, where only certain combinations are allowed.
• "Menu" of available forecasts/parameters may vary with model run (often there may be a difference between 00:00/12:00 and 06:00/18:00 model runs), and also there may be some data leaks. So in a real world the Forecast may depend on Run dimension. A proper solution to this would require a change in WMS specification - allowing advertising of dependant dimension values = enumeration of all allowed Run&Forecast combinations.

Multiple time range semantics

Quite a comprehensive list of time range options is formalised in the GRIB1 format (for example see http://dss.ucar.edu/docs/formats/grib/gribdoc/timer.html)

Possible solutions:

• Put this reference into layer name/title
• Put this information into layer's abstract

Get time and Time series

How to specify a list of times?

WMS 1.3.0 specification, page 46, Table C.2 - WMS dimension can declare its capability to accept multivalue or range inputs, even ability to provide result interpolated for input values. But there is another problem is the uncertain semantics of GetMap? query output. For example if you query WMS for a list of times - what should be the expected result? Single image which integrated data for all times display or an animation? Obviously in case of time dimension, the animation looks more logical, but if you imagine a "accumulated rainfall" layer, than time specification could simply describe the integration period. Note that variety of image formats supporting animation is very limited comparing to range of still image data - but this issue goes beyond MetOceanDWG? scope...

Time & GetCapabilities?

The statement above is not true - See WMS 1.3.0 spec, page 47, C.3.2. WMS layer can have TIME dimension - this is quite a widely spread practice especially due to WMS EO profile.

Synthesis of works under construction (updated November2009)

Time concepts for forecasted data

1- Concept of Validity date

TIME parameter : There is a consensus to use the TIME parameter to define the date. This will make clients that don't handle the dimensions usable.

As WMS - Application Profile for EO Products, the TIME parameter should be mandatory for "live data"

2- Concept of RUN

DIMENSION : A request can be made on the run. It has to be a dimension.

Name : RUN_START_TIME (to be confirmed)

Default: last run

Grammar : Iso8601

3- Concept of Time Range

DIMENSION :

Name : FORECAST_OFFSET (to be confirmed)

Default: 0

Grammar : Iso8601

Use Cases :

• How to manage that the best run is not always the last (NWS suggested via the Default, Fred wondered if this has to be handled via CSW BEST_RUN, LAST_RUN or ALL_RUNS requests)
• How to handle the users that don't want to wait until all run available (Ben talked about the need for local model initialisation but this would rather be for WCS)
• How to handle multiple runs for the same time. Suggestion : new DIMENSION : RUN_ID

Time concepts for climatological data

1- Concept of Monthly climatology DIMENSION :

Name : (to be confirmed)

Default:

Grammar : Iso8601:2004 not adapted. Should use Iso 8601:2000?

Time concepts for Observations

Are the concepts of O&M of samplingTime and resultTime sufficent ?

07-022r1_Observations_and_Measurements_-_Part_1_-_Observation_schema.pdf : "The samplingTime is the time that the result applies to the feature-of-interest. This is the time usually required for geospatial analysis of the result. The resultTime is the time when the procedure associated with the observation act was applied. For some observations these are identical, in which case the resultTime may be omitted."

Teleconferences minutes or working groups reports

18 January 2010 : Minutes of the 5th Teleconference on Time issue

11 January 2010 : Minutes of the 4th Teleconference on Time issue

14 December 2009 : Minutes of the 3rd Teleconference on Time issue

25 Novembre 2009 : Workshop use of OGC standards in Meteorology :Report of the working group on Web services : See file attached

16 Novembre 2009 : Minutes of the 2st Teleconference on Time issue

9 Novembre 2009 : Minutes of the 1st Teleconference on Time issue

26 Novembre 2008 : Workshop use of OGC standards in Meteorology : Report of the working group on Web map services : See file attached

-- MarieFrancoiseVoidrotMartinez - 20 Jun 2009