Skip to content

Commit

Permalink
- aggregate_polygon: The data cube implicitly gets restricted to th…
Browse files Browse the repository at this point in the history 
…e bounds of the polygons as if filter_polygon would have been used afterwards. #101
  • Loading branch information
@m-mohr
m-mohr committed Dec 17, 2019
1 parent 387b7f3 commit 71e0e6d
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 1 deletion.
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Default values are now specified on the parameter-level, not in the JSON schemas.
- Processes supporting multiple data types in parameters or return values with `anyOf` are now listing the data types directly as array. `anyOf` is discouraged.
- `add_dimension`: Parameter `value` renamed to `label`.
- `aggregate_polygon`: The data cube implicitly gets restricted to the bounds of the polygons as if `filter_polygon` would have been used afterwards. [#101](https://github.com/Open-EO/openeo-processes/issues/101)
- `clip`: Works on a single value instead on arrays (replaced parameter `data` with `x`). [#75](https://github.com/Open-EO/openeo-processes/issues/75)
- `debug`: Replaced with a completely new definition. [#82](https://github.com/Open-EO/openeo-processes/issues/71), [API#100](https://github.com/Open-EO/openeo-api/issues/100), [API#214](https://github.com/Open-EO/openeo-api/issues/214)
- `filter_bands`: Merged parameters `bands` and `common_names`. [#77]( https://github.com/Open-EO/openeo-processes/issues/77)
Expand Down
2 changes: 1 addition & 1 deletion aggregate_polygon.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@
}
},
"returns": {
"description": "A vector data cube with the computed results.\n\nThe computed value is stored in dimension with the name that was specified in the parameter `name`.\n\nThe computation also stores information about the total count of pixels (valid + invalid pixels) and the number of valid pixels (see ``is_valid()``) in each geometry. These values are stored as attributes of the result value with the attribute names `total_count` and `valid_count`.",
"description": "A vector data cube with the computed results. The vector data cube implicitly gets restricted to the bounds of the polygons as if ``filter_polygon()`` would have been used with the same values for the corresponding parameters after this process.\n\nThe computed value is stored in dimension with the name that was specified in the parameter `name`.\n\nThe computation also stores information about the total count of pixels (valid + invalid pixels) and the number of valid pixels (see ``is_valid()``) in each geometry. These values are stored as attributes of the result value with the attribute names `total_count` and `valid_count`.",
"schema": {
"type": "object",
"subtype": "vector-cube"
Expand Down

4 comments on commit 71e0e6d

@jdries
Copy link
Contributor

@jdries jdries commented on 71e0e6d Dec 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we say:
Process graphs that use aggregate_polygon do not necessarily have to specify spatial filters, as this can be derived from the provided vector data.

@m-mohr
Copy link
Member Author

@m-mohr m-mohr commented on 71e0e6d Dec 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference to the proposal?

@jdries
Copy link
Contributor

@jdries jdries commented on 71e0e6d Dec 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's subtle, but I'm trying to make it clear to backend implementors that they should use the bounding box from the polygons.
I've also been thinking about some kind of 'backend implementation suggestions' in the process documentation, to clarify things like this.
On the other hand, possibly the better option is to add a compliancy test that simply does it, that's often simpler than trying to put everything into written language.

@m-mohr
Copy link
Member Author

@m-mohr m-mohr commented on 71e0e6d Dec 18, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last two paragraphs make sense as the processes itself are written primarily written for users so that we should try to avoid implementation details as much as possible. The two options named are good solutions for that.

I'm not really agreeing with the initial proposal as it may still be good to implicitly define a spatial filter in load_collection for example.

Please sign in to comment.