Copyright © 2010, Open Geospatial Consortium, Inc. Met Ocean Time Issue Resume Met-Ocean DWG 72nd OGC Technical Committee Frascati, Italy 8 March 2010 Sponsored and hosted by ESA/ESRIN

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium Basic Issue - Time has 1, 2 or 2.5 dimensions TIME= parameter in OGS requests is not sufficient Two basic time approaches in MetOcean domain –Observations - time just 1D - here TIME dimension is sufficient –Forecasts, 3 parameters defining 2 dimensions with some incomplete combinations: Analysis initialization base time – here-in-after referred as RUN Proposed DIM_name : RUN_START_TIME Forecast offset – here-in-after referred as OFFSET Proposed DIM_name : FORECAST_OFFSET Validity (or forecast) time TIME = RUN + OFFSET Forecast/validity may have different semantics: –Fixed time validity (not an issue), –Validity time ranges - 3h, 6h, accumulation = relative time from analysis initialization base time Focus on WMS but same applies to WCS, WFS, …

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium Multidimensional time Model Run TimeConstant Validity Time Only a subset of product RUNxOFFSET is available: Number of OFFSETs in particular RUN may vary Higher OFFSETs in the same RUN may have coarser step For one Constant Validity Time multiple different forecasts are available Rapid updates (even hourly or tens of minutes) Range available validities depends on the module run time because validity and run time axes are not orthogonal.

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium Multidimensional time Picture courtesy of John Caron, UCAR Model Run Best Estimate Constant Forecast Offset Constant Valid Time Only a subset of product RUNxOFFSET is available: Number of OFFSETs in particular RUN may vary Higher OFFSETs in the same RUN may have coarser step For one Constant Validity Time multiple different forecasts are available Rapid updates (even hourly or tens of minutes)

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium A1. Single layer for all runs (described by Trond Michelsen at WMS Layer represents particular parameter (e.g. Temperature, Pressure, …) while RUNs, OFFSETs (and TIMEs) are listed in GetCapabilities as WMS dimensions Pros –Convenience - client can control what he gets. –If only TIME is supplied as argument, WMS can return Best Run estimate. –Closest to current meteorological practice in terms of common retrieval semantics which are used in the forecasting process: RUN & OFFSET TIME RUN & TIME Cons –Some of combinations of RUN & OFFSET are not available and will return and exception. –Many RUN & TIME combinations are not available. May require WMS extension to describe WMS dimensions dependencies (e.g. DescribeLayerDimensions request).

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium A2. Separate runs into layers or services (described by Jon BLower at Model RUN is represented as separate layer OR as a dedicated service end-point. Available forecast validity TIMEs are listed in GetCapabilities. Pros –All RUNs are properly enumerating their forecast validity offsets and there are no invalid RUN&TIME combinations Cons –Layers or service end-points appear & disappear within the time, clients cant remember them. –Large number of Capabilities documents –Best Run semantics requires dedicated Best Run Layer or Best service end-point –Implies rapid update of CSW

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium A3. Separate runs into layer hierarchy bProposed by Michael Weis and Joseph Matula Using WMS layer tree to group same parameters: –Parent layer provides Best Run selection with TIME dimension –Child layers represent different RUNs listing corresponding available forecast TIMEs Pros –All RUNs are properly enumerating their forecast validity offsets and there are no invalid RUN&TIME combinations. –Best Run semantics is built-in. –No need for service catalogue. Cons –Unusual approach making it more difficult to read for machines (despite easy for humans). –Larger Capabilities document. –Layers appear & disappear within the time, client cant remember them

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium Other common issues Clients have to refresh Capabilities documents BUT what is the ideal period?. Latest run is usually the Best, BUT not always. Best Forecast for certain validity time is not always from the Best Run (older model run may describe weather in certain region or time range better). Handling CSW updates if layers/services appear/disappear in time. RUN does not become available at once, but within tens of minutes or hours as model computes forecast - partial data availability is sometime desired. We have much more dimensions (different vertical coordinates - levels, ensemble model members, …) - more details detailed description of dimensions will be necessary anyway. Are there any related plans/thoughts in other OGC domains?

Helping the World to Communicate Geographically Copyright © 2010 Open Geospatial Consortium Summary of approaches we revised A1 - is based on existing WCS work, but to be fully correct it requires more detailed description of dimensions (dependencies). It allows unification all access semantics (TIME, RUN&TIME, Best Run, Best Forecast). A2 - based again on some existing works (treating different model runs as different service end-points). Increases complexity of requests due to external catalogue use. A3 - theoretical, but creative approach. In principal similar to A2 just avoiding the need of catalogues.