You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VectorCubes are one of the important new concepts at the moment.
Adding full support is probably going to take a couple of iterations, so this is probably going to be an epic/grouping ticket.
As discussed, I think we would benefit in terms of future complexity if DriverVectorCube._geometries can be reduced to a gpd.GeoSeries instead of a gpd.GeoDataFrame. This means that DriverVectorCube._cube would have dimensions [geometry, time (optional), bands (optional)] and all property data is loaded in as separate bands.
I would also argue to not allow a "properties" dimension in DriverVectorCube._cube, but to always refer to it as "bands".
DriverVectorCube._geometries can be reduced to a gpd.GeoSeries instead of a gpd.GeoDataFrame
FYI: using a GeoDataFrame in DriverVectorCube in addition to a DataArray for the "cube data" was/is intentional to separate geometry/feature properties from the cube data, based on initial brainstorming on vector cubes. Now there is some consensus to cast properties to the cube data to simplify things, but that might complicate other things as well: e.g. see
This means that DriverVectorCube._cube would have dimensions [geometry, time (optional), bands (optional)] and all property data is loaded in as separate bands.
note that DriverVectorCube._cube probably also still has to be nullable (e.g. value None) when there is no cube data. For example when loading a single GeoJSON Polygon with load_geojson. Related:
Activity
EP-3981 Add #71 #114 references to vector cube todo's
EP-3981 #114 add tests for aggregate_spatial with vector cubes
EP-3981 Add #71 #114 references to vector cube todo's
EP-3981 #114 add tests for aggregate_spatial with vector cubes
EP-3981 #114 add more DriverVectorCube tests
soxofaan commentedon Apr 20, 2022
DummyDataCube)Removed old, unused `zonal_statistics` stubs from openeo-python-driver
Bump version to 0.18.1a1
EP-3981 #114 DriverVectorCube: add `from_geojson` and `to_wkt`
EP-3981 #114 add `to_vector_cube` process (custom) for converting Geo…
EP-3981 #114 Bump version to 0.18.2a1
Issue #114/#141 convert inline GeoJSON in aggregate_spatial to Vector…
fixup! Issue #114/#141 convert inline GeoJSON in aggregate_spatial to…
28 remaining items
Issue #114/#211/#197 tests for `load_geojson` and its `properties` arg
fixup! Issue #114/#211/#197 tests for `load_geojson` and its `propert…
Issue #114/#211/#197 from_geodataframe: add dummy cube when no proper…
fixup! Issue #114/#211/#197 from_geodataframe: add dummy cube when no…
fixup! fixup! Issue #114/#211/#197 from_geodataframe: add dummy cube …
Issue #114/#211/#197 tests for `load_geojson` and its `properties` arg
Issue #114/#211/#197 from_geodataframe: add dummy cube when no proper…
Issue #114/#211/#197 bump version to 0.61.0a1
Issue #114/#211/#197 bump version to 0.61.0a1
Issue #114/#211 initial support for `load_url` (vector cubes)
Issue #114/#211/#197 vector cube `apply_dimension`: put results in cu…
JeroenVerstraelen commentedon Feb 2, 2024
As discussed, I think we would benefit in terms of future complexity if DriverVectorCube._geometries can be reduced to a gpd.GeoSeries instead of a gpd.GeoDataFrame. This means that DriverVectorCube._cube would have dimensions [geometry, time (optional), bands (optional)] and all property data is loaded in as separate bands.
I would also argue to not allow a "properties" dimension in DriverVectorCube._cube, but to always refer to it as "bands".
soxofaan commentedon Feb 2, 2024
FYI: using a GeoDataFrame in DriverVectorCube in addition to a DataArray for the "cube data" was/is intentional to separate geometry/feature properties from the cube data, based on initial brainstorming on vector cubes. Now there is some consensus to cast properties to the cube data to simplify things, but that might complicate other things as well: e.g. see
note that
DriverVectorCube._cubeprobably also still has to be nullable (e.g. valueNone) when there is no cube data. For example when loading a single GeoJSON Polygon withload_geojson. Related:load_geojsonissues openeo-processes#448Note that
load_geojsonat the moment explicitly specifies usage of the "properties" dimension of type "other":https://github.com/Open-EO/openeo-processes/blob/965bbaebd4d5984203a0437076c85a66a72a23e0/proposals/load_geojson.json#L21
So we have to be careful when deciding to deviate from that current spec (e.g. first try to push for a different convention in the spec). Related:
load_geojsonissues openeo-processes#448#71 #114 #268 added TODO notes on deprecation of GeometryCollection
Harden DriverVectorCube restriction in aggregate_spatial/filter_spati…