Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VectorCube support #114

Open
soxofaan opened this issue Apr 20, 2022 · 3 comments
Open

VectorCube support #114

soxofaan opened this issue Apr 20, 2022 · 3 comments

Comments

@soxofaan
Copy link
Member

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.

related/subtasks:

@soxofaan
Copy link
Member Author

  • implemented vector cube based aggregate_spatial (in python driver's DummyDataCube)

soxofaan added a commit that referenced this issue Apr 22, 2022
related to EP-3981 #114
soxofaan added a commit that referenced this issue Apr 22, 2022
soxofaan added a commit that referenced this issue Apr 22, 2022
soxofaan added a commit that referenced this issue Oct 6, 2022
soxofaan added a commit that referenced this issue Oct 6, 2022
soxofaan added a commit that referenced this issue Oct 6, 2022
soxofaan added a commit that referenced this issue Oct 7, 2022
soxofaan added a commit that referenced this issue Oct 7, 2022
soxofaan added a commit that referenced this issue Oct 7, 2022
soxofaan added a commit that referenced this issue Oct 7, 2022
soxofaan added a commit that referenced this issue Oct 7, 2022
soxofaan added a commit to Open-EO/openeo-geopyspark-integrationtests that referenced this issue Oct 12, 2022
soxofaan added a commit that referenced this issue Oct 12, 2022
…inline Point GeoJSON to VectorCube in aggregate_spatial
soxofaan added a commit that referenced this issue Oct 18, 2022
…oint geometries in aggregate_spatial

reverts 2ec255e and 4927eee
openeo-geopyspark-driver now properly supports point geometries
jdries added a commit that referenced this issue Mar 29, 2023
soxofaan added a commit that referenced this issue Aug 2, 2023
- flattening: move options to export phase iso vector cube constructor
- introduce `VectorCube.from_geodataframe` wiith support for promoting selected columns to cube values
- regardless of promotion: all properties are still associated with `VectorCube.geometries` for now (otherwise properties can not be preserved when using `aggregate_spatial`, see Open-EO/openeo-api#504)
- only promote numerical values by default for now
soxofaan added a commit that referenced this issue Aug 3, 2023
- flattening: move options to export phase iso vector cube constructor
- introduce `VectorCube.from_geodataframe` wiith support for promoting selected columns to cube values
- regardless of promotion: all properties are still associated with `VectorCube.geometries` for now (otherwise properties can not be preserved when using `aggregate_spatial`, see Open-EO/openeo-api#504)
- only promote numerical values by default for now
soxofaan added a commit that referenced this issue Aug 3, 2023
- flattening: move options to export phase iso vector cube constructor
- introduce `VectorCube.from_geodataframe` wiith support for promoting selected columns to cube values
- regardless of promotion: all properties are still associated with `VectorCube.geometries` for now (otherwise properties can not be preserved when using `aggregate_spatial`, see Open-EO/openeo-api#504)
- only promote numerical values by default for now
soxofaan added a commit that referenced this issue Aug 4, 2023
soxofaan added a commit that referenced this issue Aug 4, 2023
soxofaan added a commit that referenced this issue Aug 4, 2023
soxofaan added a commit that referenced this issue Aug 4, 2023
soxofaan added a commit that referenced this issue Aug 4, 2023
@JeroenVerstraelen
Copy link
Contributor

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
Copy link
Member Author

soxofaan commented Feb 2, 2024

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:

I would also argue to not allow a "properties" dimension in DriverVectorCube._cube, but to always refer to it as "bands".

Note that load_geojson at 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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants