How to represent a seasonal climate normal?

[petergarnaes]

Sorry if this is not the right place to raise this issue, but I am curious how to properly represent a climate normal of a season in coverage json.

If I have a climate normal for 1981-2011 for the December, January, Feburary (DJF) season, how would I go about representing it in terms of the time axis? The simple way would be:

{
  "type" : "Coverage",
  "domain" : {
    "type" : "Domain",
    "axes": {
      "t" : { "values": ["1996-01-16"], "bounds": ["1980-12-01", "2010-03-01"] }

But this does not capture that only the winter months within those bounds are actually covered.

You could do something like:

{
  "type" : "Coverage",
  "domain" : {
    "type" : "Domain",
    "axes": {
      "t" : { "values": ["1996-01-16"], "bounds": [
        ["1980-12-01", "1981-03-01"],
        ["1981-12-01", "1982-03-01"],
        ["1982-12-01", "1983-03-01"],
        ...
     ] }

But the standard says this about bounds:

An axis object MAY have axis value bounds defined in the member "bounds" where the value is an array of values of length len2 with len being the length of the "values" array. For each axis value at array index i in the "values" array, a lower and upper bounding value at positions 2i and 2*i+1, respectively, are given in the bounds array

Which the latter example clearly violates.

I'm just a developer, so maybe I'm overthinking this? Is the first approach the correct one? Or is this simply not possible yet, and maybe relates to #9 in a way that I don't realize?

[jonblower]

Hi - this is a good question. Representation of climatological statistics is currently beyond the scope of the CovJSON spec. It can be handled in the CF conventions, which might form a template for how to make it work in CovJSON.

I don't think either of the examples you give really capture the information (and as you say, the second one actually violates the spec) - unfortunately I can't think of anything better within the current spec.

Philosophically, CovJSON is intended as a kind of "transient" format for transmitting data from web servers to web browsers, to enable some processing and visualisation to be done in the browser. The data themselves would probably be kept on the server in a more suitable "archive" format like NetCDF. The assumption is that the processing in the browser context would be quite limited, so we haven't tried to push CovJSON to capture every detail that other metadata structures do. But of course if there was sufficient demand from the community then this could be done, probably based on CF.

[jonblower]

P.S. I don't think this directly relates to #9, although they are both about representing time. #9 is more about dealing with forecast run collections, which have two time dimensions.

[petergarnaes]

Ah, I see, thanks for the clarification!

I guess CovJSON is not suitable output for all EDR APIs, even though it is strongly recommended to support CovJSON. Or rather, option 1 is what you would have to content with.

[jonblower]

Do the EDR APIs have a concept of climatological statistics then? I wasn't aware of that

[chris-little]

@jonblower API-EDR supports almost anything as a variable/parameter/observable, such as climate normal for 1981-2011 for the December, January, Feburary (DJF) season. @petergarnaes I had hoped that the OGC Statistics DWG would help standardise the specification of various useful statistics in an interoperable way, but the WG has sunk without trace. The W3C Ontology Time is probably not that useful for construction of descriptions of such statistics.

[jonblower]

@chris-little would I be right in thinking that in EDR the variable would just be given as a string (or a term from a controlled vocab) rather than somehow mathematically describing the statistic in a machine-readable way? In which case this could simply be done in CovJSON through the label and description of the observedProperty. If there is a term from a controlled vocab, that's even better as this can be used as the id. Does that make sense @petergarnaes ?

[petergarnaes]

@chris-little would I be right in thinking that in EDR the variable would just be given as a string (or a term from a controlled vocab) rather than somehow mathematically describing the statistic in a machine-readable way? In which case this could simply be done in CovJSON through the label and description of the observedProperty. If there is a term from a controlled vocab, that's even better as this can be used as the id. Does that make sense @petergarnaes ?

@jonblower

EDR describes variables almost identically to CovJSON, here's a snippet of the example listed in the EDR standard:

            "parameter_names": {
                "Wind Direction": {
                    "type": "Parameter",
                    "description": "",
                    "unit": {
                        "label": "degree true",
                        "symbol": {
                            "value": "°",
                            "type": "https://example.org/edr/metadata/units/degree"
                        }
                    },
                    "observedProperty": {
                        "id": "http://codes.wmo.int/common/quantity-kind/_windDirection",
                        "label":  "Wind Direction"
                    },
                    "measurementType": {
                        "method": "mean",
                        "period": "-PT10M/PT0M"
                    }
                },
                ....

It's straight forward mapping it to CovJSON, except measurement type, which I guess would have to be included in the CovJSON description.

In regards to controlled vocabulary to be used with the id, I don't see the CF conventions use any controlled vocabulary for standard_name or variables for seasonal climate normals (called climatology in the CF conventions). I can't find anything in the standard names table either.

But maybe you're saying I could define a standard vocabulary and do something like:

  "observedProperty" : {
    "id" : "http://vocab.dmi.dk/standard_name/climatology_seasonal_spring_mean_temperature/",
    "label" : {
      "en": "Mean temperature of of all springs within climate normal"
    },
    "description" : {
      "en": "..."
    }
  },

Is that understood correctly?

[chris-little]

@petergarnaes Yes - having a string as an interim apporach would work. I was keen to develop a standard interoperable "language" for climatological statistics, but the Statistics Working Group disappeared and is very dormant, if not actually dead. The Temporal Domain WG currently hasn't the expertise or capacity to define something.

OGC API-EDR part 1: Core, Version 1.2 will almost certainly optionally support the CF Methods table to support the measurement type. See PR#472 .

HTH. @m-burgoyne @jonblower for info.

[jonblower]

But maybe you're saying I could define a standard vocabulary and do something like:

Yes - the id should be a URI from a controlled vocabulary, but of course this can be any vocabulary. The client won't be able to "understand" the way the statistic is calculated, unless the URI resolves to some machine-readable description.

Maybe the measurementType structure could be ported from EDR to CovJSON, although I haven't looked into it.