vector_buffer: result of shrinking until there is nothing left?

[bossie]

Process ID: vector_buffer

Describe the issue: We've run into this edge case where applying a negative buffer to a small polygon resulted in an empty (shapely) polygon. It's not clear what the result of this process should be.

Additional context: https://github.com/Open-EO/openeo-geopyspark-driver/issues/314

[m-mohr]

Good point. What do you think should happen? Throw an error? Empty geometry?

[jdries]

We were a bit unsure:

• if we filter out the empty geometries by default, it may appear like a feature got lost
• if we make it an 'empty geometry' that would need to be supported by vectorcube and all subsequent processes

We now throw an error, but would be better if we can also make it somehow work for this case.

[m-mohr]

Yes, I'd need input from the different back-ends so that we standardize what the tooling actually does or what makes most sense, i.e. find hopefully a common denominator. Otherwise, throwing an error is always the last resort.

[m-mohr]

Details for VITO: https://github.com/Open-EO/openeo-python-driver/issues/164

[m-mohr]

Why is it an issue in downstream processes to have empty geometries/coordinates? @jdries In the discussion it sounds like the preferrable option would be to handle empty geometries. We were not sure what the downstream issues are.

GeoJSON supports empty geometries/coordinates.

[jdries]

Handling empty geometries everywhere is indeed an option, perhaps also the best one as it would result in least errors for the users. The main issue with it is that a lot of existing (open source) implementations do not support empty geometries, and thus errors are thrown, often badly readable. Hence, openEO backend implementors will have to add explicit support in all vector processes.

[m-mohr]

@jdries Thanks. Which implementations are this? In the call it seemed people were at least not so concerned about the Python ecosystem. Spark?

[jdries]

For us, it's a mixture of Python and Scala (geotrellis), but I don't think it can be linked to an ecosystem. In general, it's safe to assume that there will for sure exist implementations that do not deal well with it, and it needs to be tested case by case. So in any case, we can perhaps move forward with documenting handling of empty geometries in vector cubes?

[m-mohr]

Do you mean on a case-by-case basis per process? Or generally in openEO? For the latter I'm not sure what we could document apart from that maybe empty geometries should be supported and if not, they get removed or so?

On a per-process basis:

• vector_buffer: Add a note that the process may generate empty geometries.
• load_geojson: Add a note that empty geometries are added to the data cube.
• aggregate_spatial: Empty geometries do exist in the result without any statistics
• apply_polygon / filter_bbox / filter_spatial / load_collection / load_result / mask_polygon / filter_vector: Empty geometries are ignored
• vector_to_random_point / vector_to_regular_points: Empty geometries are passed through, no points will be assigned.

Sounds good?

edit: add a general comment about empty geometries to the data cube introduction/glossary.