-- Please add questions, issues, etc to this page

Introduction

It is proposed to build the Met Ocean Best Practices document following the structure of the WMS 1.3 spec to easy the parallel reading :

*Proposals discussed in Teleconf and validated in TC sessions

Handling TIME ( Also useful for WCS and WFS)

1 - Concept of Validity time ( Also useful for WCS and WFS)

Meteorological and oceanographical products are based on multiple concepts of time : validity time, 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), time range or offset, ...

An optional TIME DIMENSION is defined in the WMS 1.3.

It has been validated to make the TIME dimension mandatory ( as into the EO WMS profile) to define the validity time.

For generic WMS clients, it is the responsability of the data provider to select the default value or define his policy of nearest Value. If the data available is to far in term of validity to the requested TIME it can answer with a InvalidDimensionValue.

If Nearest value is set, it is recommended to label the response with the actual value found in an HTTP response.

2 - Concept of ANALYSIS TIME ( Also useful for WCS and WFS)

Definition : ANALYSIS_TIME describes the time instant for the initial conditions of a numerical weather simulation. The analysis Time is chosen from a time-instant toward the middle of the assimilation window where the model state is considered to be more realistic.

It has been validated to define an optional dimension named ANALYSIS_TIME

-

---

Issues to work on that impact the Met Ocean WMS best practices

Works going on : Vertical CRSs ( Also useful for WCS and WFS)

Teleconfs helped define the Vertical CRSs needed for Met Ocean WMS.We will not cover some of the vertical CRS which will probably be necessary for WCS BP but not for WMS BP. The use cases not covered into MO WMS BP will be explicited.

The underneath schema identifies the various vertical levels in use : this is what we are doing, trying to understand if they are really CRSs or something else.

Then we will need to describe them more strictly using the constructs of ISO 19111-2 - Andrew Woolf agreed to help us there.

We might then reach a problem of governance around some definitions, the identifiers enablement to 'carry some weight' within the community. this might also reach the scope of some other SWG or DWG....

Works going on : Time concepts for climatology ( Also useful for WCS and WFS)

1st Proposal (Guillaud) : to put as much semantics as possible into the layer name. aggregation of “cell methods” (e.g. : maximum within days, mean over years ..) applied to a “base phenomenon” (e.g. temperature, wind speed, wind direction, precipitation amount, …).define a methodology to convert the cell methods combination into natural (understandable) language, e.g. :

o (MEAN over DECADE ( MEAN over MONTH (MAX over DAY (TEMPERATURE )))) that is a “functional” approach to layer names :

 DecadalMonthlyMeanMaximumDailyTemperature (en)

 TemperatureMaximaleQuotidienneMoyenneMensuelleSur10Ans (fr)

2nd proposal (Rinne); suggested that it would be better if there would be no internal data structure in the Name element, but a "Keyword" element with a specific "vocabulary" attribute could be used for this information

Still to be discussed : Concept of REFERENCE_TIME_PERIOD or AGGREGATION_TIME_PERIOD

Definition : Period of reference for the values. Some parameters are calculated over a temporal period for example rain accumulation, Maximum or minimum temperature.

Still to be discussed : Layers naming

Still to be discussed : Set of 2 dimensions for Ensemble probabilistic products : THRESHOLD and OPERATOR

Still to be discussed : PROCESS

Still to be discussed : Styling

Still to be discussed : Standardize and improve GetFeatureinfo

Other issues relevant for MO WMS BP

Still to be discussed : GetCapabilities updates

The Met Ocean community is not the only one to be impacted by this issue but we can provide extreme use cases that could help other OGC experts find a global solution.

Description of the GetCapabilities extreme use cases

Previous discussions on this issue :

Get Capabilities layering or metadata and Time handling_

Issue and Works	current status summary	: Impact on the Profile doc, : Comments, : Actions
Handling of TIME dimension	TIME is validity time	For generic WMS clients the decision taken in Toulouse to offer best product OK (responsibility of the data provider to select /define his policy)
	DIM_RUN_BASE_TIME	For MO profile clients, another set of layers using TIME and DIM RUN_BASE_TIME
	DIM_FORECAST_OFFSET not needed anymore	MO Profile:. A TIME default value should be defined by the server. TIME=« Current ». It is server policy to define how to implement « Current »
	Issue: not all combinations of TIME/RUN are possible	The works here are put in standby until more Return of Experience from the I.Es or until the Modelling WG makes other proposals
	Synthesis of the Met Ocean Modelling WG works on Time- March 2011
Layers Naming
Projections /CRS	The projections needed by the community and not available at the moment are the GEOS projection and Polar Stereographic projection with arbitrary base meridian.	Identify projections of the community and explore defining URIs in the OGC namespace (as appropriate)
	Current projections referenced in the WMO GRIB data format are here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/GRIB2ver7/GRIB2_7_0_0_CodeFlag.pdf in Code Tables 3.1 to 3.10 etc, which are expanded here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/GRIB2ver7/GRIB2_7_0_0_Temp.pdf
	The GEOS projections is based on a specific ellipsoid WMO adoption of WGS84 and EGM96 are on p96 of http://www.wmo.int/pages/prog/www/ois/Operational_Information/Publications/CBS/CBS_Ext06_1017/1017_en.pdf	Evaluate the error of the approximation if GEOS supposed on WGS84 and see with WMO the possibilities to update the definition of GEOS
	Adrian Custer Liaise actively with WMS1.4 SWG	MO profile « you should not use multiple bounding boxes for a given layer unless they cross the anti-meridian, in this case they should be connected at the longitude of the anti-meridian»
		First Check works already done in WCS WG or Unidata WCS CRS works
		Support INSPIRE projections (ETRS)
Vertical coordinates	Several options have to be evaluated :
	- use the DIM ELEVATION, TIME(Pro : expected by Mass market, con : not multi layer capable)	if use of DIM or vertical CRSs , make shortcuts for T500, MSLP ?
	- use of a DIM TBD?, (Pro : multi layercapable, con work, unexpected, no general client will recognize semantic)	Look at WCS
	- put the level into the name of the layer? (Pros : easy, different styles possible/ con : doesn’t scale)	Review options considering specific use cases
	- define vertical CRSs? (Pros : compliant with WMS1.3/ con : not very detailed, governance? Examples?)	Get more information from OGC
	- 3D CRS can be defined as combination of 2D CRSx1D vertical CRS)
	Vertical coordinates used in the WMO GRIB data format are here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/GRIB2ver7/GRIB2_7_0_0_CodeFlag.pdf Tables 3.15, 3.21 and 4.5
Metadata Search and filtering	Get Capabilities layering or metadata and Time handling_	To be driven by CSW
Standardised parameter names for validation	Standard parameter names used in the WMO GRIB data format are here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/GRIB2ver7/GRIB2_7_0_0_CodeFlag.pdf Code Table 4.1 and 4.2 Standard parameter names used in the WMO BUFR and CREX data formats are here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/BUFRver16/BUFRCREX_16_0_0_TableB.pdf Table B	A simplification of WMO parameter names proposed to help automate production of URIs. ECMWF also has an online machinable table of names, but with small changes from the WMO Standard.
Styling	Ilkke Rinne and Chris Little Liaise actively SLD/SE SWG	Should define styles for WMO symbology, register these names, use in profile
		MO Profile Should define basic styles for each classical parameter and recommend to servers implementations to offer these styles
		Provide input to SLD/SE 2.0
Standardise GetFeatureInfo		Need best practice for GetFeatureInfo result information
		Agree on what GFI must return depending on the type of layer (NWP output, satellite image, radar, )?
How to improve GetFeatureInfo	Could that be used to return several types of info, e.g. vertical profile, time-series, –Either•Extend existing operation: GetFeatureInfo&info_type=vertical-profile•Create new operation: GetVerticalProfile,	May be not a WMS issue
WMS metadata : How to serve extra Metadata about WMS Layers and maps	Adrian Custer Liaise actively with WMS1.4 SWG	MO profile should then recommend to MO servers to return everything which is not exactly as specified explicitly into the client request
	Might be splitted into two issues Metadata about the service and about the data offering (projections, )AND Meta information about the map response (min max value, TIME served interpolation algorithm, ..)
Versions of different level between Servers and Clients	Version negotiation part of the standard	MO Profile: recommendations for server offering to Mass Market clients should be version agnostic
		MO Profile: should recommend to implement at least WMS 1.3.0 if INSPIRE compliancy required
		WMS2.0 might fit better MO users requirements than WMS1.3.0
Forming correct URLs		Described into WMS 1.3.0 doc
	Adrian Custer Liaise actively with WMS1.4 SWG	General HTTP Request Rules §6.3 in WMS1.3 doc : Take care this possibility is still available into WMS2.0 and makes it explicit
Animations	If server serves maps with dynamic colormaps, it can be confusing in animations	MO Profile might define recommendations for animations
	What about the image/gif MIME type
	What about frame rate
Tiling		MO DWG need to review all profile suggestions with WMTS

Issues identified during the works but out of the scope of the Met Ocean WMS best practices

Asynchronous and dynamic delivery

Aaron Braeckel Liaise actively with pub/sub SWG

The Met Ocean community is not the only one to be impacted by this issue. We have facilitate the creation of the PubSub SWG to solve this issue.

The liaison is made by Aaron Braeckel.

On this issue the needs of the MO Community identified are :

• Asynchronous delivery for off line data
• Recurrent subscription i.e. subscription to future data
• Notification of availability of new data/layer
• Notification of other changes impacting getcapabilities (e.g. using filters)
• guarantee of delivery

Integration with other systems GRIB, WCS, Opendap

Follow the works on WCS2.0 extensions

*Make sure GRIB is considered but Not in the scope of MO WMS profile*

Cross section description

Request=getcrosssection& line=lat1,lon1,…&style=?&vertical_axis=? More work is needed

A proposed template used in the WMO GRIB data format is here: http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/2010edition/GRIB2ver7/GRIB2_7_0_0_CodeFlag.pdf

template 3.1000

• Vertical CRS needs:
  

2nd proposal (Rinne ) : suggested that it would be better if there would be no internal data structure in the Name element, but a "Keyword" element with a specific "vocabulary" attribute could be used for this information

2nd proposal (Rinne): suggested that it would be better if there would be no internal data structure in the Name element, but a "Keyword" element with a specific "vocabulary" attribute could be used for this information

2nd proposal (Rinne) : suggested that it would be better if there would be no internal data structure in the Name element, but a "Keyword" element with a specific "vocabulary" attribute could be used for this information