@Teddy-1000 Sounds good. But as with title, I think the intention here is to keep it short. Include a rule for 50 characters max?

And that example from E-SOH may be from CoverageJSON, not collection? As labels in EDR collection does not currently support multi-language.

This issue is regarding the observation profile response, so this would indeed be CovJSON.
Label will have to be short. Are there any need for description to have any length limitations?

Ah, I misunderstood, sorry.

I don't think its necessary to limit description no.

I can expand this issue to also include the collection Parameter, since they are very closely connceted?
Are we good with going for the limitations of CF standard_names for ObservedProperty, and CF cell methods for method?

I think it makes sense to handle both in one PR yes, since they anyway need to be in sync. Should probably exist as separate requirments in the profile documenth though.

CF names seems good enough for me. We need to tackle exceptions maybe, but we can start with mandating CF names.

I have no experience with CF cell methods, so not sure there.

We've been discussing Parameter metadata for RODEO WP5 (Climate) as well. This is our current proposal:

"TG": {
   "type": "Parameter",
   "label": "Mean temperature",
   "description": "Daily mean air temperature, measured at 1.5 m, in degree Celcius.",
   "unit": {
       "label": "degree Celsius",
       "symbol": {
           "value": "°C",
           "type": "https://qudt.org/vocab/unit/DEG_C"
        }
   },
   "observedProperty": {
       "id": "https://vocab.nerc.ac.uk/standard_name/air_temperature",
       "label": "Air temperature"
   },
   "measurementType": {
      "method": "mean",
      "duration": "P1D"
   },
   "eumetnet:standard_name": "air_temperature",​
   "eumetnet:level": 1.5​
}

This proposal is with the following ideas in mind:

• Parameter id: Free to choose. Bears no further meaning ("TG" in example). Should not be used for display purposes in UIs.
• Parameter label: required. To be used in plots/dropdowns
• Parameter description: required. A full description of the parameter, describing all other fields in text.
• Unit required: Using QUDT as vocabulary.
  • QUDT has persistent and unique URIs per unit. Can provide translation to UDUNITS (as used in CF conventions)
  • In case no URI to vocabulary exists, use unit.symbol.description to describe the unit.
• Observed Property: The physical property being measured. Using CF convention standard_name.
  • In case no CF convention standard_name exists. Use observerdProperty.description to describe the property being measured
• Measurement Type:
  • Method: EDR spec 1.2 (in draft) now lists a set of recommended values. They are pretty similar to the CF cell methods
  • Duration: Duration of measurement within the temporal extent of the coverage. This follows the ISO 8601 Duration standard.
    • In EDR 1.1 spec this is called period in some examples. In 1.2 this has now been rectified to duration
• eumetnet:standard_name: The CF convention standard name. Should match the one in observedProperty.type. Used as custom dimension to be queried on. See below
• eumetnet:level: The height above ground level where the measurement occurs. Used as custom dimension to be queried on. See below

The eumetnet:standard_name and eumetnet:level can then be exposed as EDR custom dimension. This is similar to how ESOH is doing this. It allows for queries such as:

https://server.example/collections/observations/area?​
coords=POLYGON((-12.602 59.367,-12.954 46.580,2.169 47.061,2.169 60.769,-12.602 59.367))​
&datetime=2022-05-10T00:00Z/2022-05-10T06:00Z​
&standard_name=air_temperature​
&level=1.0/2.0

This queries for air temperature, between 1 and 2 meter. It may return one or more actual parameters, that fit these properties.

Another discussion point has been the the Parameter ID. We have chosen to give this no further meaning. In theory, it should only link parameters to ranges in the CovJSON. In practice, we expect these to may be used to reflect some internal database ID. However, this may make it difficult to retrieve parameters from different EDR APIs which are effectively equal. For example, within RODEO Climate WP5 we defined a list of Core Parameters, that all partner API should provide at a minimum (think min/max air temperature, wind speed, precipitation). To facilitate easier querying of these Core Parameters we are considering to add these as separate custom dimension.

@PaulVanSchayck Great, thank you! Could you also add an example for how this will look in the responding CoverageJSON document?

You would hope they are equal, wouldn't you. Unfortunately, the specs (EDR vs CovJSON) do differ somewhat from each other. We've not implemented this proposal yet in CovJSON, so I'm not 100% sure if I've missed anything.

"TG": {
   "type": "Parameter",
   "label": {"en": "Mean temperature"},
   "description": {"en": "Daily mean air temperature, measured at 1.5 m, in degree Celcius."}
   "unit": {
       "label": {"en":"degree Celsius"},
       "symbol": {
           "value": "°C",
           "type": "https://qudt.org/vocab/unit/DEG_C"
        }
   },
   "observedProperty": {
       "id": "https://vocab.nerc.ac.uk/standard_name/air_temperature",
       "label": {"en","Air temperature"}
   },
   "measurementType": {
      "method": "mean",
      "duration": "P1D"
   },
   "eumetnet:standard_name": "air_temperature",​
   "eumetnet:level": 1.5​
}

The most obvious difference is the i18n stuff which is present in CovJSON but not EDR. Also parameter.measurementType is not specified in CovJSON. But the spec allows extra members on parameter, so it's within the spec.