add_dimension: Type spatial always is always for z axis

[m-mohr]

Clarified that type spatial always adds a spatial dimension for the z axis.

[clausmichele]

Why can't x and y be added? A possible use case scenario could consist in:
load_collection over an AOI -> reduce_dimension over x (or y) -> add_dimension x (or y) with an "aggregated" label representing that area.

[soxofaan]

I agree with @clausmichele , is there a particular reason or background story to add this constraint?

[m-mohr]

There's no way to specify the actual axis for the spatial dimensions, so just adding a spatial dimension without axis is ambiguous. The most reasonable (and presumably most common) way out for me was to specify that it's z.

[soxofaan]

maybe use the name argument as axis identifier in some way?

[m-mohr]

That seems a little to implicit for me, what would a user get that specifies lat, lon, long, height, etc. I think defaulting to z is fine. If we ever encounter a usecase for x/y (has anyone encountered one?) we could just add an axis parameter to add_dimension that defaults to z.

[soxofaan]

what would a user get that specifies lat, lon, long, height, etc.

yeah, but when adding a dimension with name "lat" or "lon" or "long" it also does not make sense to do that with axis "z".

Also what if the cube already has an axis "z"?

What about something like

... If the type is spatial, the axis is the first option that does not exist yet from "x", "y", "z"

or

... If the type is spatial, the axis depends on the dimension name: names "x", "lon", "long" map to axis "x", names "y", "lat" map to "y", and all other options map to "z"