Get capabilities layering or metadata

Introduction

The issue there is to select a layer granularity : Have the parameters needed to define a product to be handled as DIMENSIONS or as component of a complex long name?.

  • Example for Satellite imagery :
    • LAYER=SA__OBS__MSGC__V_EURATL__WV-62
    • Or
    • LAYER= SA__OBS__MSGC__V_EURATL_WV DIM_Waveband=62
    • Or
    • LAYER=SA_OBS DIM_Platform=MSGC DIM_NativeDomain=V_EURATL DIM_ChannelType=WV DIM_Wavelength=62

A possible approach is to define multiple URLs to define several services (One by data set or model run). A balance between “Service URL” and layering or Multi-dimensional layers (LAYER plus DIM) have to be found.

The DIMENSIONS usage have to be defined :
  • should they be dedicated to define spatial metadata as : DIM_Quality, DIM_PixelTimeStamp ?
  • Or
  • can they be used to define the basic product ? DIM_Wavelength=62, 73, 108 , DIM_AccumulationTime=5, 15, 60 …DIM_BaseTime ,

Note WMS allows using vendor/implementation specific parameters in the URL, so in some cases dimensions can be replaced by extended parameters in the GetMap query. Such behaviour can be properly advertised in the <_ExtendedCapabilities> or <_ExtendedOperations> section of GetCapabilities response (see WMS 1.3.0 spec, page 13, chapter 6.9.5).

In any case defined terms of names and units have to be defined.:

*The granularity of the layers will impact kiss
  • The efficiency of catalogue searching
  • The size of GetCapabilities response and performances

Remarq : The OpenGIS Web Map Services Application Profile for EO Products (OGC 07-063) have discussed similar issues. It has to be taken into account.



Discussions yes

The teleconf of the 22nd of March agreed to gather some examples of GetCapabilities provided by existing implementations.

Into the Questionnaire, Helen Korsmo from the Research & Development Department, Norwegian Meteorological Institute already provided this example :

http://wms.met.no/cgi-bin/getcapabilities.cgi?map=/metno/eksternweb/wms/vhosts/interrisk/conf/sse.map

followed by these comments :

"We have two problems regarding dimensions

If a layer has multiple dimensions, it's assumed that all combinations of all dimensional values are available. A layer might have data for time=1990/2000/P1Y where elevation=0, but only 1996/2000/P1Y for elevations 500, 1000 or 2000. We have not found a way to express this dependency between time and elevation in the WMSCapabilities document. A current workaround is to define multiple layers, one where elevation=0 and one where elevation="500,1000,2000"

A layer might have several mutually exclusive dimensions. e.g. a layer might have data for 1000, 850 and 500hPa, and also for 0, 500 and 1000 meters above ground. In this case, the first dimension will be named "pressure" and the second will use "elevation". In this case, the client must include elevation=value OR dim_pressure=value in the GetMap? request, but the standard requires the client to include both (unless one or both have defined default values). In this case too, the workaround is to define multiple layers, one for each available dimension "

-- MarieFrancoiseVoidrotMartinez - 22 Jun 2009

UKMO Examples

We (mostly) break down WMS services into different NWP models or observational types. Please see attachments (no link to an internet facing WMS server available).

GlobEGRR and NAE1EGRR are the UKMO Global and North Atlantic and European deterministic models. A combination of DIM_RUN and DIM_FORECAST is required to retrieve a layer for a particular time. The TIME dimension can be exposed in the metadata, but is not generally used. "default" values for DIM_RUN are set using a simple time delay of hours/minutes after the datatime of the model run. It is our policy to not allow requesting users to not be able to see a model "arrive" and built up T+ time after T+ time. DIM_FORECAST values are only applicable to the "default" DIM_RUN. This policy enables our applications, which parse the GetCapabilities into an animation menu, to always have a representative set of images to request. As mentioned in the Norwegian section above, we cannot display all combinations of DIM_FORECAST for each DIM_RUN and ELEVATION available for each layer. If you could, the resulting document would be massive.

A note on the _S1, _S2 postfix. We tend to not use alternative styles unless very easily definable, for example 4hPa pressure intervals instead of 2hPa. It is generally easier and more wieldy within the config of VisualWeather to have alternative layers for the same parameter, denoted with an incremental style identifier.

RADAR and SATELLITE services contain RADAR and SATELLITE data. The time delay on these is set at zero, so the images are available as soon as they have arrived and have been processed. These services use the TIME dimension.
I Attachment Action SizeSorted ascending Date Who Comment
SATELLITE.xmlxml SATELLITE.xml manage 18 K 23 Mar 2010 - 15:20 MattWardle UKMO Satellite data WMS GetCapabilities
GlobEGRR.xmlxml GlobEGRR.xml manage 31 K 23 Mar 2010 - 15:20 MattWardle UKMO Global Model WMS GetCapabilities
NAE1EGRR.xmlxml NAE1EGRR.xml manage 39 K 23 Mar 2010 - 15:20 MattWardle UKMO NAE WMS GetCapabilities
RADAR.xmlxml RADAR.xml manage 65 K 23 Mar 2010 - 15:21 MattWardle UKMO RADAR data WMS GetCapabilities
Topic revision: r5 - 23 Mar 2010, MattWardle
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback