This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• About 20 participants– ECMWF, met services, vendors, universities
• Two sessions of 1h30
• Focus first on WMS and the time issue
• Aim: stick to existing standards whenever possible, and map met. vocabulary to existing dimension, to be compatible with other WMS client (e.g. validity time mapped to <TIME> dimension)
• Note:– The “DIM_” prefix is only used in requests, not in GetCapabilities
documents. The standard must make that clear and should not use “DIM_” when naming dimensions in the wiki or other documentation (see practice of other WG)
• Consecutive calls to GetMap on the same layer may deliver different images:– When new observations are available (or corrected)– When a new model run is available
• Use of default (e.g. latest or “best”)– Most of the time latest = best– But will break caching– How often should a client call “GetCapabilities”?
• Could this information be provided as part of the GetCapabilities document itself?• Or provide layer update frequency? (This may already be part of related
• Run:– Base time, reference time, run (hour | time), run start time– Forecast reference time (CF)– We need a default (e.g. latest) for support for WMS clients
• Forecast time :– Valid time, validity time, verification time– (Just) Time (CF)– Proposal: GetCapabilities <TIME> extents only contains the absolute
</layer><layer name=“temperature_2” title=“The day before yesterday’s forecast”>
…</layer>…
</layer>
• Issue: difficult to manage (produce and use), generate large GetCapabilities.• Compatible with existing WMS client• Does not represent impossible combinations (unlike proposal 1) • To be further explored…
• Should we agree on the names of all <dimensions> and the range of values of <extents>, or should WMS client be ready to support for any names– E.g. Should the name “forecast_probability_threshold” be agreed by the
community– In short, should we give any semantic to dimension names, or are they
just character strings
• WMS allow clients to ignore dimension
• Recommendation: MetOcean group to provide governance on dimension names (MetOcean checked if the dimension has already been proposed, process similar to CF convention)
– “Climatological bounds” : statistics are computed over a time interval– Climatological statistics may also be derived from corresponding
portions of a “range” of year (seasons), month, day, and therefore need a specific “climatological” axis
e.g :– Average temperature for each climatological seasons over 1970-1999– Decadal max/min temperatures for January over 1970-1999 – Hourly average temperatures are given for April 1997. – …
• From OGC Observations & Measurements (07-022r1)– “Sampling Time”
• the time that the result applies to the feature-of-interest”.
– “Result Time” • “the time when the procedure associated with the observation act was
applied”
• Other time properties– “Collection period”
• the time interval bounding all discrete observations within the collection
– “Process Period” (part of the phenomenon definition ?)• Time interval relative to validity time for accumulations, averages, max/min • Similar to the climatological bounds• E.g : rain accumulation over 3 hours
– “Issue Time” • Time at which the observation was published … allowing for amendments