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 :

*Available systems

Servers :

• ECMWF 1.1.1
• IBL 1.1.0, 1.1.1, 1.3.0
• Met.no1.1.1
• ncWMS(Reading University) 1.1.1, 1.3.0
• BADC 1.1.1, 1.3.0
• KNMI –Adaguc1.1.1
• NOAA –>=1.1.1
• Nexrad–>=1.1.1

Clients :

• Metview-all
• 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.

• Forming correct URLs...:

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 at 2?

• 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 update.

• • HTTP expires
  • GetCapabilitessequence to say it has changed
  • Other protocols: RSS to notify

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

• Animation on clients:

Most of the clients had facilities for animation, but more developments need to be done.

Conclusion

• 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

Participants

• ECMWF
• DWD
• IBL
• Met.no
• University of Reading
• KNMI

-- MarieFrancoiseVoidrotMartinez - 11 Jun 2010