Add vector cubes #59
Add vector cubes #59
Conversation
m-mohr
force-pushed
the
vector-cubes
branch
2 times, most recently
from
07f32fb
to
10035f6
Compare
m-mohr
requested review from
aljacob,
clausmichele,
dthiex,
jdries,
mattia6690,
mkadunc and
soxofaan
|
I've updated the PR to reflect recent discussions. Please re-review! |
|
Ready for final review. |
documentation/1.0/datacubes.md
Outdated
|
|
||
| Dimension labels are either numerical or text (also known as "strings"), which also includes textual representations of timestamps for example. Dimensions with a natural/inherent order are always sorted. These are usually all spatial and temporal dimensions. Dimensions without inherent order, `bands` in openEO for example, retain the order in which they have been defined in metadata or processes (e.g. through [`filter_bands`](https://processes.openeo.org/#filter_bands)), with new labels simply being appended to the existing labels. | ||
| Dimension labels are usually either numerical or text (also known as "strings"), which also includes textual representations of timestamps or vectors for example. | ||
| Usually, vector labels (geometries) are encoded as [Well-known Text (WKT)](https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry) and temporal labels are encoded as [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) compatible dates and/or times. |
There was a problem hiding this comment.
We discussed this elsewhere I think, but are WKT strings a good choice for labels?
- the WKT string can become very large (kilobytes or worse), which does not make it a handy label to work with in the different phases of a user workflow
- there is quite some room for variation in WKT encoding of a geometry due to float representation/precision or vertex ordering.
There was a problem hiding this comment.
Side question: what does the "usually" refer to here: "usually in the remote sensing/GIS community", or "usually in openEO implementations"?
There was a problem hiding this comment.
| Usually, vector labels (geometries) are encoded as [Well-known Text (WKT)](https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry) and temporal labels are encoded as [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) compatible dates and/or times. | |
| For example, geometries (i.e. the labels of a geometry dimension) can be encoded in [Well-known Text (WKT)](https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry) or GeoJSON like temporal labels are usually encoded as [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) compatible dates and/or times. |
There was a problem hiding this comment.
The labels can be chosen by the user, could be ID, WKT2, any other attribute. Doesn't need to be unique, back-ends can have an internal UID (e.g. index)
There was a problem hiding this comment.
you mean that in the sense of as follows?:
- When supported by the back-end implementation: the labels can be chosen by the user: could be ID, WKT2, any other attribute. Doesn't need to be unique.
- As fallback, back-ends can use an internal (unique) id (e.g. auto-increment index, UUID, hash function of geometry, ....)
There was a problem hiding this comment.
I'm not sure whether back-ends should be able to not support it, but we also don't know yet at which point/how users can choose this. So this is to be discussed in openeo-processes.
I guess back-ends always need an internal unique id in addition to the representation.
|
Do not allow mixing geometry types (only allow one geometry type + the corresponding multi type). |
|
I've updated the PR to reflect (I hope) our discussions today. I'd appreciate a final review! Thanks. Changes since the meeting: 10cdca0 @soxofaan @mkadunc @aljacob @clausmichele @jdries @dthiex @LukeWeidenwalker @pierocampa |
m-mohr
requested review from
edzer,
soxofaan,
LukeWeidenwalker and
pierocampa
and removed request for
mattia6690
|
The substance of what's written looks all good to me - just a few minor suggestions on the prose, apply whichever you agree with ;) |
Co-authored-by: Lukas Weidenholzer <17790923+LukeWeidenwalker@users.noreply.github.com>
Adding high-level explanations about vector data cubes.