Closed letmaik closed 8 years ago
Yes, I think your approach is sound. My only worry would be that it’s quite easy for a data producer just to stick the axis names in the array, irrespective of whether they are single-or multiple-valued. It takes a small amount of extra thought to remember to omit the single-valued axes. But I don’t think it’s a big deal. Maybe if a data producer accidentally inserts the name of a single-valued axis the client could simply ignore it.
It would still be allowed to include single-value axis names. It's just that they are not strictly required.
Hmm, maybe I have to rethink that. I didn't consider the case of all-fixed axes, like for Point. Then at least one axis would suddenly be required again, which then is again arbitrary. Maybe let's leave it as it is then.
If all axes are fixed, then each Range only has one value. So the axisNames
field is redundant and could even be omitted (or empty?). In any case, clients wouldn't need to read it at all, right?
Sure, but then it's not a proper nd-array anymore. There has to be at least one dimension, otherwise it's something different. I'd rather have a consistent approach with a 1-element nd array instead of inventing another range type like "SingleValue".
what does xarray do in this situation?
Hmm, xarray wraps numpy, and numpy actually supports 0D arrays:
>>> foo = xr.DataArray(np.array(12.4), dims=[], coords={'time': '2002'})
>>> foo
<xarray.DataArray ()>
array(12.4)
Coordinates:
time <U4 '2002'
time
is an additional coordinate here, not related to the array dimensions.
You would access that single element with foo[()]
, while foo[0]
throws an error, which makes sense. So it's kind of a degenerate nd array.
Interestingly, the ndarray library in javascript automatically wraps a single element into a 1D array, but if you then pick
that axis element, then it reduces to a 0D array.
So, ok, too much worrying from my side again. Let's just do it. 0D arrays, without shape and axisNames, or optionally shape=axisNames=[].
ok sounds good
Funny, coincidentally my library covjson-reader already supports leaving out axisNames and shape, due to its backwards-compatibility with the old range structure (where rangeAxisOrder was optional in the Domain object). I'll change the spec accordingly now.
Changed it, the coverage examples of the common domain types spec look much nicer now. Less clumsy.
I was thinking, since we now have a standalone range in the form of an NdArray object, would it make sense to allow to leave out non-varying axes? This would be how typical labelled-array libraries handle that, like xarray. In xarray, the DataArray is a bit like a Coverage with one parameter, and there the array data has varying dimensions and associated coordinates, but the DataArray/Coverage object itself also can have other coordinates, like a fixed time coordinate.
I think to make NdArrays less awkward and promote the use of domain axes for additional non-varying things (like country ID, or fixed time) it would be good to not force the NdArray to have all axes of the domain. This would also reduce the confusion of which order to choose for those additional axes.
Client-side I don't see any complications.