Proposal for replacing variable object with bands #30
Description
The idea is that instead of having a variable object you have a band object:
| Existing Field Name | Proposed Field Name | Type | Description |
|---|---|---|---|
| dimensions | cube:dimension_refs | [string] | REQUIRED. The dimensions of the variable. This should refer to keys in the cube:dimensions object or be an empty list if the variable has no dimensions. |
| type | cube:type | string | REQUIRED. Type of the variable, either data or auxiliary. |
| description | description | string | Same as in the band definition |
| extent | statistics.minimum/statistics.maximum | nested object | The minimum and maximum of the values within the variable array. Same as in the band spec definition |
| values | cube:values | [number|string] | An (ordered) list of all values, especially useful for nominal values. |
| unit | unit | string | Same as in the band spec definition |
| nodata | nodata | number|string | Same as in the band spec definition |
| data_type | data_type | string | Same as in the band spec definition |
- We didn't notice the unit/units issue originally and we need more discussion on that topic
Originally identified pros and cons:
Should datacube use bands?
- Cons:
- bands typically share units whereas variables don't necessarily
- it is not the typical word in this domain
- Pros:
- tooling might expect bands and if you don't provide them then the tooling needs to know how to handle that.
- if we push on with using bands more heavily (as in Emmanuel's PR) we can stay aligned.