EURODEO / rodeo-edr-profile

This is a repository to make EDR profiles used in EURODEO visible for all use
https://rodeo-project.eu/rodeo-edr-profile
Creative Commons Attribution 4.0 International
2 stars 0 forks source link

Parameret object in observations profile collection and data response #22

Open Teddy-1000 opened 1 month ago

Teddy-1000 commented 1 month ago

Many parts of the Parameter object are quite straight forward. Most difficult to define I think is the parameter-id, since this might be used by clients.

I do suggest we make a parameter label mandatory and description optional.

 "parameter-id": {
      "type": "Parameter",
      "description": "text description of parameter", # optional
      "label": "short text label of parameter", # mandatory
      "unit": {
        "label": "as written", # mandatroy
        "symbol": "any unicode symbol" # optional
      },
      "observedProperty": {
        "id": "URI to vocab/standard names", # mandatory, should be part of a vocab. CF?
        "label": "short text label of observedPropery" # If CF, this should be the standard name
      },
      "measurementType": {
        "method": "", # aggregation method for observation, suggest CF cell methods
        "period": "" # ISO8601 duration
      },
      "rodeo:level": 10 # instruments height above ground
    },

This is a current example of how E-SOH format of a parameter. It does not have a parameter label yet. First is from a data query, seconds is from a collection response.

    "air_pressure:150:mean:60": {
      "type": "Parameter",
      "description": {
        "en": "air_pressure at 1.5m, aggregated over PT1M with method 'mean'"
      },
      "observedProperty": {
        "id": "https://vocab.nerc.ac.uk/standard_name/air_pressure",
        "label": {
          "en": "air_pressure:150:mean:60"
        }
      },
      "unit": {
        "label": {
          "en": "hPa"
        }
      },     
   "measurementType": {
        "method": "mean",
        "period": "PT1M"
      },
      "rodeo:standard_name": "air_pressure",
      "rodeo:level": 1.5
    }
    "air_pressure:150:mean:60": {
      "type": "Parameter",
      "description": "air_pressure at 1.5m, aggregated over PT1M with method 'mean'",
      "unit": {
        "label": "hPa"
      },
      "observedProperty": {
        "id": "https://vocab.nerc.ac.uk/standard_name/air_pressure",
        "label": "air_pressure:150:mean:60"
      },
      "measurementType": {
        "method": "mean",
        "period": "PT1M"
      },
      "rodeo:standard_name": "air_pressure",
      "rodeo:level": 1.5
    }

Any feed back or discussion can be done here, or else I will get to creating a PR for this.

havardf commented 1 month ago

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

Teddy-1000 commented 1 month ago

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?

havardf commented 1 month ago

Ah, I misunderstood, sorry.

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

Teddy-1000 commented 1 month ago

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?

havardf commented 1 month ago

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.