copyright © 2009, open geospatial consortium, inc. web services report from the working group of...

Copyright © 2009, Open Geospatial Consortium, Inc.Copyright © 2009, Open Geospatial Consortium, Inc.

Web Services Web Services Report from the working group of 2nd Report from the working group of 2nd

Workshop on GIS/OGC Use in Meteorology Workshop on GIS/OGC Use in Meteorology

Frédéric Guillaud, Marie-Françoise VoidrotOGC Met Ocean DWG, 71st OGC Technical Committee

Mountain View, CA. USADecember 9, 2009

2

Helping the World to CommunicateGeographically

Copyright © 2009 Open Geospatial Consortium

WG - Services

• 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)

3



Time & Met data high rate refresh

• 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

metadata, e.g. associated WMO core record)

4



The time parallelogram (is not a rectangle…)

Latest

Sam

e <T

IME

>S

ame validity

“Best” forecast

Reference time

Offset

FuturePast

All possible valid dates

<TIME> only available in 5 runs out of 10

5



Time – Concepts & Vocabulary (forecasts)

• 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

date/time for the latest forecast

• Forecast period– Forecast offset, offset– Step : Step(n+1) = Offset(n+1) – Offset(n)

• Reuse GRIB2, BUFR or CF names when possible• <TIME> dimension is compulsory (in GetCapabilites)

6



Time – Vocabulary (forecasts ranges)

• Accumulation, Min/Max, averages,…– Practice: several…

• [Start offset, End offset]

• [Start , Start + range]

• [Middle – range/2 , Middle + range/2]

• [End – range, End]

– What is the validity time?• Average: in the middle

• Accumulation: at the end

• Min, max?

– Again, check what is done in CF, GRIB2, BUFR

7



Capabilities : Proposal 1

• For a given <LAYER>, the <TIME> dimension refers to the most recent <REF_TIME>

<Layer><Dimension name=“TIME”>T1,T2,T3</Dimension><Dimension name=“OFFSET”>O1,O2,O3</Dimension><Dimension name=“REF_TIME” default=“R3”>R1,R2,R3</Dimension>

</Layer>

• T1,T2,T3 which Ti= R3 +Oi • All combinations of TIME/STEP/REF_TIME may not be valid• Advantage: compatible with simple WMS clients

8



Proposal 1 (graphically …)

Reference datesValid dates (<TIME>)Steps

9



Proposal 1.5 (best estimate time series)

<TIME> = ref. time followed by valid time

Warning: Simple WMS clients will get different maps for the same <TIME> when requested on different days.

Reference datesValid datesSteps

10



The time “parallelogram” revised …

Intermediate runs with short forecast offset

Last run still running …

Step depends on the offset

11



Capabilities : Proposal 2

• Use layer hierarchy, group all forecast of the same model for different runs• Parent layers hold common attribute

<layer name=“temperature” title=“Best estimate (forecast + previous analysis)”><Dimension name=“ELEVATION”>1000/850/500</Dimension><Dimension name=“TIME”>a0,a1,…,t1,t2,t3</Dimension><layer name=“temperature_0” title=“Current forecast ”>

<Dimension name=“TIME”>t1,t2,t3</Dimension>…

</layer><layer name=“temperature_1” title=“Yesterday’ forecast”>

<Dimension name=“TIME”>t0,t1,t2</Dimension>…

</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…

12



Vertical coordinates (elevation)

• Several CRS : – “true” h (CRS:88) – often inappropriate, pressure, sigma, hybrid,

flight level…– Native dimension “elevation” :

e.g : <elevation units=“hPa”>1000, 500, 200</elevation>• Check for ISO 19111-2 compliance

• If not, Met Ocean needs to define missing vertical CRS (check with INSPIRE)

• How to mix levels types ?e.g : <elevation units=“any”>1000hPa, 500hPa, 10m</elevation>

• not standard?

• Any other <dimension> ?

13



Other dimensions (1/2)

• When a layer needs to be parameterised, how to decided whether to use a new dimension, or make the parameter part of the layer name ?

E.g :LAYER=ALADIN_20091123000000_36H_T_850

LAYER= ALADIN_T_850 DIM_RUN=2009-11-23T00:00:00Z DIM_FORECAST_OFFSET=36H

LAYER=ALADIN DIM_RUN=2009-11-23T00:00:00Z DIM_FORECAST_OFFSET=36H DIM_LEVEL_TYPE=PRESSURE DIM_LEVEL_VALUE=850 DIM_PHENOMENON=T

• Caution : The granularity of the layers will impact : – The efficiency of catalogue searching

– The size of GetCapabilities response and performances

6 offsets * 10 days * 20 levels * 20 phenomena = 24000 LAYERS !

14



Other dimensions (2/2)

• 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)

15



General issues

• Layer names should not have any semantics– Semantics go in a dimension

• Tiles/Images should come back with associated metadata– Geo-location– Time– Other dimensions

• Notification– Availability of new model run

16



Other issues (not discussed)

• CRS– Vertical longitude of polar stereographic– Equirectangular BBOX spanning the anti-meridian

• Styles– SLD / SE (Symbology Encoding) sufficient for our community?

17



Other time topics out of the scope of the working group report

(mentioned in the TWIKI and teleconferences)

New issues raising out of the current works regarding climatology and observations

18



Time – Concepts & Vocabulary Climatology

• 3 variables (axis) can be introduced (according CF NetCDF conventions 1.4) :

– “Cell Method” or “Statistical Process” : accumulations, averages, max/min, …)

– “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. – …

19



Proposals regarding the time issue for climatology

• The “statistical process” is not directly linked to the time issue, but can be handled with a specific dimension : CELL_METHOD

• Handle the climatological process period (or bounds) with the native TIME parameter (ISO8601 encoding)

• The rules for the “climatological axis” (dimension) are still to be discussed :

– ISO19108 time ordinal reference system (TM_OrdinalEra within a TM_OrdinalRefecenceSystem)

– Name of the dimension : CLIMATOLOGICAL_TIME ?

– Grammar for values :• Abbreviated or partial date time ( hyphen in place of omitted date elements),

but not currently used :– E.g DIM_CLIMATOLOGICAL_TIME=-11- for November encoding YYYYMMDD

• Compliant ISO 8601:2000 but not ISO 8601:2004 ? (Provision removed)

20



Time – Concepts & Vocabulary Observations

• 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

21



Proposals regarding the time issue for observations

• Check consistency with Observations & Measurements model (OGC 07-022r1)

• Need to map time properties onto native WMS time parameter, dimensions or layer metadata

• Native time dimension would be used for SamplingTime or CollectionPeriod

• Possible dimension for “ProcessPeriod”

• Other time properties treat as metadata ?: – IssueTime, ResultTime, ..

22


Copyright © 2009 Open Geospatial ConsortiumCopyright © 2009, Open Geospatial Consortium, Inc.Copyright © 2009, Open Geospatial Consortium, Inc.

Thank you for your attentionThank you for your attention

copyright © 2009, open geospatial consortium, inc. web services report from the working group of...

Documents

time latest

validity time

base time

hour time

time issueaim

wms clientsforecast

best estimate time series

simple wms clientshelping