EGOWS (European Group on Meteorological Workstations) is a working Group that gathers once a year developpers and users of meteorological systems mainly for forecasters or production.
Created in 1989, this group was originally European but it welcomes regularly participants from outside Europe (Canada, Australia or China...).
During the last workshop (01-04 june 2010) at ECMWF a session of 2 or 3 hours was dedicated to connect various clients and servers for an interoperability test on the 03 of June afternoon. No specific use case was provided.
These are the conclusion of this trials :
- ECMWF 1.1.1
- IBL 1.1.0, 1.1.1, 1.3.0
- ncWMS(Reading University) 1.1.1, 1.3.0
- BADC 1.1.1, 1.3.0
- KNMI –Adaguc1.1.1
- NOAA –>=1.1.1
- Visual Weather (+ web client –flex based) -all
- Ninjo(+ web) 1.1.1
- BADC web -1.3.0
- KNMI web client -1.1.1
*Issues to look out for
- Versions different between Servers and Clients:
Some Clients were not checking the version used by the server in the
getCapabilities documents. They were misinterpreting the
document, specially in the use of the bounding box and in the definition
of the dimensions.
There is a need for negotiations of versions between clients and servers.
- Different projections offered/used :
There were some remarks on the quality of the getCapabilities
documents: it was noted that some servers were advertising a large numbers
of SRS in their top layers, but were not able to deliver the layers in all
the advertised projections. (NOAA server)
- Ratio of image should not be changed by server:
Some servers are changing the size of the requested image to respect the
aspect ratio of the projection. It was mentioned that the result image
should always have the size specified in the WMS request(width/height),
even if this means a wrong aspect ratio of the projected area.
Some clients had trouble to use the https protocol.
Some clients are building automatically the getCapabilities request and
therefore have trouble to add additional parameters that a WMS may need.
(Reading University servers)
It was mentioned that if a form of authentication is needed it could be
send as a token before the ? of the request.
- How to handle no Time given for models:
Some servers do not give default for time. Clients have then difficulties to present a meaningful value to the users.
It was mentioned that default for "dynamic dimension" such as time should
be better decided on the server side. Servers are more skillful to decide what the "best time" is.
- Interpretation of the getCapabilities:
Some bugs or features were found on clients :
- Some assume that legendURL is mandatory
- Some assume that they will always find a BoundingBox
- Some had problems with interpretations of certain dimensions.
A discussion went on the naming of layers, and their discriminations:
Should the 2 m temperature field be accessible through a layer called 2mt
or through a layer called temperature with a dimension height or elevation
- Time: getCapabilities versus client time:
There were some technical discussions about the use of the concept of
nearest_value, and what technical solutions could be used
to inform the client that it did not receive what it asked for?
It was mentioned that such a feedback could come in the HTTP headers.
- Update Notification of the getCapabilities documents:
Some technical solutions were discussed on how to inform the client that the
getCapabilities document is no more valid and that it has to ask for an
- Automatic generation of user interfaces on the client side:
It could be useful to add in the getCapabilities documents some
informations (hints) of how best a dimension and its possible values can
be presented to the users.
In the case of date/time, it was mentioned that a nice user interface
could be very difficult to create in case of long time-series ( Ex: 1
image radar every 15 mn for the last year).
It was also mentioned, that for such long series, it could be challenging
to ensure that all the advertised dates in the getCapabilities document
are effectively available on the server side.
Most of the clients had facilities for animation, but more developments
need to be done.
- Many combination worked, spontaneously
- Need more testing with ‘general purpose’ GIS clients
- Recording of results:
- Post Snapshots and text on MetOcean Wikihttp://external.opengeospatial.org/twiki_public/bin/view/MetOceanDWG/MetocWMS_IE_Implementations
- University of Reading
- 11 Jun 2010