-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
|
…JSON in aggregate_spatial to VectorCube
…JSON in aggregate_spatial to VectorCube
…inline Point GeoJSON to VectorCube in aggregate_spatial
- 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
- 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
- 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
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". |
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
Note that |
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:
The text was updated successfully, but these errors were encountered: