Constraint on id for a collection

[havardf]

What rules works best here?

Some alternatives:

• WIS 2 topic notation? weather.surfaceobservations., weather.prediction.,
• Similar to WIS 2 topic notation, but Rodeo specific: rodeo.metnorway.surfaceobservations?
• Reverse hostname notation?
• WIGOS based?
• Specific hardcoded id for each profile, e.g surfaceobservations?

[mrauhala]

I don't know if it is relevant to think here, but there is some discussions how to link data from different apis. Let's say we have ecmwf surface data from EDR to create for example timeseries. Then I have same data in map from OGC WMS or OGC API Maps. How to create services so that it is possible to link parameters / layers between apis.

[havardf]

I don't know if it is relevant to think here, but there is some discussions how to link data from different apis. Let's say we have ecmwf surface data from EDR to create for example timeseries. Then I have same data in map from OGC WMS or OGC API Maps. How to create services so that it is possible to link parameters / layers between apis.

I guess it would be a metadata catalogue that would link a certain record of a dataset to multiple services for accessing it for vector, raster etc. I guess that catalogue could link to services where the same dataset has different identifiers, but of course that could be confusing.

Solving identical identifiers for the same dataset across services seems however to be something we can not solve here?

[ernstdevreede]

Linking WMS layers to EDR parameters from the same datasource would indeed benefit from having equal names for parameters in WMS and EDR (for the use case of clicking on a map and retrieving the corresponding EDR data for that point that @mrauhala mentioned above). Achieving a correspondance like that over datasets from different sources (ECMWF forecast vs ESOH observations for example) would be very hard to achieve.

About the collection id's I think it only makes sense to define the constraints on these id's if similarly named collections have the standardized structure and contents. This would already call for a large scale data harmonization, that I expect to be challenging for a system like ESOH. In other words you can only harmonize collection id's if the collections are harmonized.

[ernstdevreede]

From the point of view of GeoWeb there currently are no rules for defining collection id's. All collections are treated equally at the moment.

[ways]

From our meetings we found out that an identifier for a collection should be picked from an enumerated lists (surface_temperature, radar_observations) if the data matches. If other, custom data, do whatever.

List must be created.

[havardf]

Suggesting for a start on this list:

surface_observations
radar_observations
weather_warnings
climate_observations
weather_forecast

Or do surface_observations need something more specific to separate stationary from moving stations? stationary_surface_observations?

We should probably also add some text to the effect: postfix the id if a provider needs to have more collections of the same type.

@mrauhala @Teddy-1000 What do you think?

[Teddy-1000]

I think surface_observations have to cover too many types of observations, I don't know what common name is used for all of these types of observations. in situ observations might cover this category better, since this include observations from planes, boats and balloons. This name might be a bit too confusing?

[havardf]

@Teddy-1000 So, in Rodeo the idea is to have one aggregated collection for all observations that are not radar/satellite? So stationary, mobile(balloons, planes etc.), ocean buoys are all covered in one collection? If so, I think insitu_observations seems correct.

[Teddy-1000]

In RODEO we have not taken steps to handle mobile stations yet. I do not have enough insight to use cases for retrieving observations to decide if we should split moving stations/platforms, and stationary stations. From a user and technical perspective, splitting these in two collections do make sense. Combing the different station types in the same output can be confusing. I would suggest something like ground_based_insitu_observations and moving_insitu_observations. moving might be a bit strange, so please suggest a better name here.