search

Open-EO / openeo-processes

Interoperable processes for openEO's big Earth observation cloud processing.
https://processes.openeo.org
Apache License 2.0
49 stars 14 forks source link

`add_dimension`: Type spatial always is always for `z` axis #496

Open m-mohr opened 5 months ago

m-mohr commented 5 months ago

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

clausmichele commented 5 months ago

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 commented 5 months ago

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

m-mohr commented 5 months ago

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 commented 5 months ago

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

m-mohr commented 5 months ago

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 commented 5 months ago

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"