Minutes of Telecon 12 December 2011

Attendees

• Jeff de la Beaujardiere
• Ben Domenico
• Marie-Francoise Voidrot (Meteo-France)

Discussions :

1) Met OCean WMS Best Practices draft on Time handling

During the Met OCean Session in the Brussels TC, I have introduced a new presentation of the synthesis of the discussions around the Best practices. As decided previously, the Best Practices document will follow the structure of the WMS 1.3 specification document in order to easy the parallel reading for developpers. So does the map : it follows the structure of the WMS 1.3 specification :

During the TC, we have discussed the options for the TIME DIMENSION which is pre defined into the specification :

Previous works had recommended to define the TIME dimension as not mandatory in order to be interoperable with general purpose clients that would not set it.

During the Met Ocean session, this position was changed towards the recommendation to define the TIME as mandatory but be ready to receive request without TIME.
Which means that we would be consistent with the EO Profile but more requiring on the servers as we would require to set defaults values when EO profile doesn't.

Considering the nearest value that some considered as dangerous because it could lead to a situation where the server could answer with data from November to a request asking for data from May, Jeff de la Beaujardiere said that it is not clear into the spec but when he implemented it he add to set a condition where the server can refuse to answer if it considers that the data he could serve are not acceptable compared to the request. (in blue into the schema)

This should close the discussions on the TIME dimension.

During the teleconf of the 12Th december 2011, we have tried to focus on the specific DIMENSIONS to be defined to handle Met Ocean specificities.

DIMENSIONS definition is compliant with the spec.

Previous teleconf agreed on the necessity to define an ANALYSIS_TIME dimension. The name of this DIMENSION has been defined out of the works on the modelling.

A definition is proposed :

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

This DIMENSION has to be optional and its definition (as requiered in §C2 annex C) should look like the one of the TIME .

At this point , participants wondered if we should define 3 types of Best Practices :

- One for the Providers ( to implement the servers)

- One for the users (to tell whihc parameter to set to talk to the servers) ,

- One for the operator (to recommend the criteria to select the data to choose and send, set the defaults...)

May be making one doc but with a lot of examples defined in a systematic way from the 3 different points of view would be enough.

The suggestions are welcome there.

2) Next telco

We had no time to discuss the other proposals of DIMENSIONS and it will be the subject of the next teleconferences.

Considering the time handling , there is still 2 proposal of DIMENSIONS :

- RESULT TIME , out of the modelling group

- REFERENCE_TIME_PERIOD : proposed by Meteo-France

And then there will still be to find a solution for the climatological use cases :

-- MarieFrancoiseVoidrotMartinez - 13 Dec 2011