Additional alternative range formats (e.g. OPeNDAP, (Geo)TIFF)

[letmaik]

This is a continuation of #44. Through internal discussion and feedback from outside, the request for alternative range formats comes up quite a lot, especially with the use case of integrating CovJSON into existing infrastructures. So we should support that in an easy way that doesn't affect JSON-only clients and doesn't rely on content negotiation (since this is not always available).

The following is a copy of an email of mine:

The idea is that the current "ranges" property stays as it is but we add a new one called "rangeAlternates" (coming from the Link relation type "alternate") which would look like that:

"ranges" : {
  "TEMP" : "http://example.com/TEMP.covjson"
},
"rangeAlternates": {
  "uor:dap2": {
    "TEMP": {
      "type": "uor:DAP2NdArray",
      "dataType": "float",
      "axisNames": ["y","x"],
      "shape": [180, 360],
      "uor:offset": 40,
      "uor:factor": 100,
      "uor:missingValue": 999,
      // or:
      // "uor:validMin": 0,
      // "uor:validMax": 50,
      "urlTemplate": "http://my.opendap.server/data.dods?air_temp{y}{x}"
    }
  },
  "uor:tiff": {
    "TEMP": {
      "type": "uor:TIFF2DArray",
      "dataType": "float",
      "axisNames": ["y","x"],
      "shape": [180, 360],
      "uor:channel": 0,
      "url": "http://example.com/data.tiff"
    }
  }
}

Some details:

• The keys inside the "rangeAlternates" object are identifiers for the encoding, here using the prefix:suffix way of using extensions.
• The value of each "rangeAlternates" property must be an object and cannot be a URL since that would otherwise mean that we introduce random new root level CovJSON document types (like "type": "uor:DAP2NdArray"). This is reserved for the CovJSON range types.
• The "ranges" property must always point to CovJSON range types.
• If someone doesn't want to publish ranges in CovJSON format (which is not recommended), then the "ranges" object is empty, which the spec actually already allows, but this has to be explicitly clarified. "ranges": {}.
• By keeping "ranges" and not merging it all in "rangeAlternates" the native CovJSON encoding is kept as the "canonical" encoding which should be used primarly, with the option of adding other encodings with slightly more effort.
• As you see in the TIFF case above I did not add a complicated RangeSet composite which associates multiple parameters to a single tiff, rather I added a channel field if the tiff has multiple channels. This keeps it simple and is also more flexible I think. Clients would be clever enough to not fetch/decode a TIFF twice for multiple parameters if those live in different image channels.

Regarding the spec, the only things to do would be to make it clear that "ranges" can actually be empty, and to define the optional "rangeAlternates" property. The spec wouldn't define any of those alternative range formats, that's purely done via extensions.

@jonblower agreed to the above plan.

[letmaik]

I just had the idea of naming the field "alternateRanges" which I think matches the "ranges" field a bit better than "rangeAlternates". Should we use that?

[jonblower]

Yes, alternateRanges maybe sounds a bit better. My only worry is that this might make it sound like this is "alternative data" rather than "the same data in an alternative format". But maybe I'm worrying too much.

[letmaik]

Hm... I think you're right. The initial one makes more sense semantically. An analogy could be a user profile image which exists in several formats. Then calling it profileImageAlternates makes slightly more sense then alternateProfileImages.