Implicit bounding box filtering by aggregate_polygon

[jdries]

In the geopyspark backend, we currently use the bounding box of the geometry/feature collection specified in 'aggregate_polygon' as an alternative to 'filter_bbox' or spatial_extent in load_collection.

This is very convenient for the user, as he does not have to extract the bounds himself, which can be annoying, especially when working with large files, or when trying to write process graphs that take any file as input.

Is this something that we should clarify in the process definition, or can we leave it implicit? (Compatibility across backends would be affected if other backends choose not to support this.).

This unit test in our backend tries to show the type of process graphs that we want to support:
https://github.com/Open-EO/openeo-python-driver/blob/5c32f52363de96977745e6c9d43214e8086b4e70/tests/test_views_execute.py#L499

[m-mohr]

I guess the best way to find out would be to just make a PR and propose this change on the call on Thursday.

[lforesta]

This is very convenient for the user, as he does not have to extract the bounds himself, which can be annoying, especially when working with large files, or when trying to write process graphs that take any file as input.

For this the user can use filter_polygon instead of filter_bbox, no?

Anyway, I also would implicitly filter data when using aggregate_polygon (we have not yet implemented this process)

[jdries]

Telco conclusion: agreed to improve documentation.
Some notes:

• Explain the mechanism and conditions when a spatial filter can be 'pushed down'
• Explain that backends might still throw an exception if the push-down behavior is not supported
• Point user to 'filter_polygon' which can make his process graph more robust across different backends

[m-mohr]

What is "push-down behavior", @jdries? Seems like an internal optimization?! I don't think this is something a user would really understand or care about. It sounds reasonable to just say that aggregate_* also implicitly applies filter_*.

[m-mohr]

See PR #109 for a proposal.

[lforesta]

PR #109 ?

[m-mohr]

Indeed, 101 is this issue.

[m-mohr]

Merged.