Repository navigation
Deprecate GeometryCollection in favor of FeatureCollection (e.g. DelayedVector) #71
Description
see Open-EO/openeo-processes#253:
In VITO backend code we use GeometryCollection as a collection of separate geometries, for which separate aggregations should be calculated for example. In Open-EO/openeo-processes#253 there is discussion to deprecate GeometryCollection usage as much as possible and promote FeatureCollections instead.
In DelayedVector (and other places) we do things the other way around at the moment: when we get a FeatureCollection, we convert it to a GeometryCollection.
Changing this will probably cause some nuisance, e.g. in the interaction between geopyspark driver and in UDFs that depend on this behavior.
Activity
soxofaan commentedon Jun 1, 2021
FYI: Open-EO/openeo-processes#253 has been merged, so now it's "official" that GeometryCollections have to be considered to be a single geometry, and that FeatureCollections have to be used to aggregate over separate geometries.
soxofaan commentedon Jun 1, 2021
(internal ticket/ref: EP-3893)
soxofaan commentedon Jul 12, 2021
Also see: Open-EO/openeo-processes#270
soxofaan commentedon Feb 23, 2022
related to EP-3981 (add vector cube support) too
EP-3981 Add #71 #114 references to vector cube todo's
EP-3981 Add #71 #114 references to vector cube todo's
DriverVectorCube.from_geojson: add support for Point/MultiPoint/Geome…
#71 #114 #268 added TODO notes on deprecation of GeometryCollection
soxofaan commentedon Jun 7, 2024
related: MultiPolygon should also not be (ab)used as a collection of geometries: #288