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?

---

---

---

---

Synthesis of works under construction (updated June 2010)

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, other alternatives RUN_BASE_TIME)

Semantic meaning : Time of the analysis of a numerical model simulation. The analysis is considered as 'the best' estimate of the state of the system. It is also the reference time of the simulation to define the offsets or time ranges.

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."

Time concepts into other standards

O&M 1.0 : samplingTime (TM_Object, Mandatory) , resultTime (TM_Object, Optional)

"An observation may involve a complex process over an extended period. For a generic observation this is summarized in two time-related properties. 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."

O&M 2.0 :phenomenonTime (TM_Object, Mandatory) , resultTime (TM_Object, Mandatory), validTime ((TM_Object, Optional)

phenomenonTime : "describe the time that the result applies to the property of the feature-of-interest … the phenomenon time is the temporal parameter normally used in geospatial analysis of the result";

" describe the time when the result became available, typically when the procedure associated with the observation was completed … for some observations this is identical to the samplingTime. However, there are important cases where they differ";

resultTime : ";.simulations may be used to estimate the values for phenomena in the future or past. The phenomenonTime is the time that the result applies to, while the resultTime is the time that the simulation was executed";

validTime : ";If present, the attribute validTime: TM_Period shall describe the time period during which the result is intended to be used …. This attribute is commonly required in forecasting applications";

The Met Ocean Modelling Wg is pushing the works on this basis as decribed into Jeremy Tandy proposal in Exeter (Nov 2010).

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.

---

---

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