vector_to_regular_points: Drop or duplicate vector properties for independent points?

[m-mohr]

We recently added a "group" parameter to vector_to_regular_points so that either MultiPoints or individual points are generated.

For MultiPoints it's easy to keep vector properties.
For Points you'd need to duplicate the vector properties. Is that intended? Right now it's documented to drop the properties. The program would also need to generate new IDs then.

Origin: #315 (comment) and #315 (comment)

[soxofaan]

What a user probably wants is to keep properties like landcover class, scene classification, etc
What an implementer probably wants to drop/replace is a property that acts as unique identifier.

What might help is to extend the vector cube definition to have a dedicated identifier property (a unique identifier associated with each geometry). At load time it can be populated from a user specified property, or, if that is missing, autogenerated (e.g. autoincrement int)

For the "ungrouped" version of "vector_to_regular_points" you can then specify:

• the id property is dropped and fully replaced with new ids
• all the other properties are kept/duplicated

[m-mohr]

This is actually a much broader discussion that we need to have, regardless of this process. Essentially, what do you do with the metadata that is not part of the data cube? See also Open-EO/openeo.org#58 (comment)

[m-mohr]

I've changed to "vector properties are generally preserved", but for MultiPoint the ID is also preserved while for Points new IDs must be assigned.

[clausmichele]

I do not see why the ID must be different from other properties, in my opinion we should just duplicate all of them. Or we need to define it as a mandatory field of a vector-cube.
The back-end can still have another indexing column which can be kept internally for working with the vector-cubes.

I've added a comment here https://github.com/Open-EO/openeo-processes/pull/352/files

[m-mohr]

Can't see the comment in the PR, but the ID must change for points because otherwise, it's not unique anymore. I assume IDs should be always unique?

[clausmichele]

But the question is, does a feature/geometry always need to have an unique ID? If yes, I've missed this.

The geoJSON samples that I've sent around some time ago didn't have any ID field but only geometries plus some properties.

[m-mohr]

No, indeed, an ID is likely not required.