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
We're trying to support/implement a use case that depends heavily on vector cube manipulation and some questions related to load_geojson came up (based on 2.0.0-rc.1 spec, other refs: #427#322):
description states "Feature properties are preserved", but the process only preserves properties specified in the properties parameter, which is empty by default, so no properties are preserved by default actually
properties has default value empty array [] but it is unclear what should happen in this case: there is only a geometries dimension with labels, but no "cube data".
Is it valid to have (vector) data cube e.g. with shape (N, 0) (N labels along "geometries" dimension and zero labels along "properties" dimension)?
Or should we in that case add a dummy label in the "properties" dimension and give all "pixels" a no-data value, so that the cube at least has a shape (N,1)?
Iterating further on the empty cube problem: description states "A new dimension with the name properties and type other is created if at least one property is provided.". I wonder if it wouldn't be cleaner to just always add this "properties" dimension, regardless of the number of provided properties. Then e.g.:
empty properties array [] => "properties" dimension with single dummy label and no-data values
single property in properties array, e.g. ["population"] => "properties" dimension with single label "population". Advantage compared to not adding the dimension is that the property name ("population" in example) is preserved
multiple properties e.g. ["id", "area", "population"] => as currently specified
related to empty cube problem: the description of "properties" param states "Only applies for GeoJSON Features and FeatureCollections. ". Does this mean that e.g. a Polygon GeoJSON object always results in such an empty vector data cube?
GeoJSON properties are typically mixed: e.g. strings and int/float. Is it valid in openEO to mix these data types within the same cube (along the "properties" dimension)?
The text was updated successfully, but these errors were encountered:
Side note regarding empty cubes: with raster cubes in load_collection we have NoDataAvailable and TemporalExtentEmpty errors, so "empty cube" seems like an error condition there
A PR based on your findings would be great so that we can discuss specific improvements.
There's room for improvement of 1+2 for sure, making more clear that it's probably no-data values/null that you want to set if no data is available. 3 also makes sense to me. Mixing data types is allowed in openEO, it's up to the implementations to decide whether they can support this or not. I would need to look into details for 4, I don't have a direct answer here.
Regarding the errors: They usually apply if there are no labels for the requested dimensions available, i.e. no data to load from. A datacube with all no-data values is not necessarily captured by that.
We're trying to support/implement a use case that depends heavily on vector cube manipulation and some questions related to
load_geojson
came up (based on 2.0.0-rc.1 spec, other refs: #427 #322):properties
parameter, which is empty by default, so no properties are preserved by default actuallyproperties
has default value empty array[]
but it is unclear what should happen in this case: there is only a geometries dimension with labels, but no "cube data".(N, 0)
(N labels along "geometries" dimension and zero labels along "properties" dimension)?(N,1)
?properties
and typeother
is created if at least one property is provided.". I wonder if it wouldn't be cleaner to just always add this "properties" dimension, regardless of the number of provided properties. Then e.g.:properties
array[]
=> "properties" dimension with single dummy label and no-data valuesproperties
array, e.g.["population"]
=> "properties" dimension with single label "population". Advantage compared to not adding the dimension is that the property name ("population" in example) is preserved["id", "area", "population"]
=> as currently specifiedThe text was updated successfully, but these errors were encountered: