add support for predefinedtilegrid in split_area #883

[VincentVerelst]

The idea is to expose the split_area function to users. Users can provide an AOI, which can be split in different ways:

• By providing a projection and tile_size: splits the AOI up in square tiles
• By providing a PredefinedTileGrid (can also be a geopandas.GeoDataFrame), which splits the AOI according to that grid
• By providing a custom subclass of TileGridInterface: splits the AOI according to their custom class

The function returns the split AOI as a geopandas.GeoDataFrame

[HansVRP]

Some initial comments and questions

[VincentVerelst]

@HansVRP , except for addressing your comments, one big change: there is now a standardized reprojecting happening to the CRS of the tile grid that is being used for splitting.

To re-iterate what will be exposes to the public API: the split_area function now takes as input an AOI, which can be split in either of two ways:

• By providing a tile-grid as geopandas.GeoDataFrame or a list of (Multi)Polygon. In the background _PredefinedTileGrid will be used for splitting
• By providing a projection and tile_size. In the background _SizeBasedTileGrid will be used for splitting. The origin will be taken to be the bottom-left of the AOI provided by the user.

Advanced users can always define their own splitting method by defining a subclass of _TileGridInterface, which is still experimental and prone to change

[HansVRP]

will look into the update; thanks.

can you also include a usecase example in: https://github.com/Open-EO/openeo-python-client/blob/master/docs/cookbook/job_manager.rst ?

[HansVRP]

@soxofaan okay to add this here?

[soxofaan]

yes, fine to add that here.

However, note that it's tricky to get this correct+intuitive for antimeridian use cases.
e.g. in antimeridian use cases, you have west > east (so min and max longitude are switched). Your polygon will then probably the opposite of what you want.

There are several possible solutions/guardrails here:

• explicit assert west < east so that you get hard fail on anti-meridian cases, instead of blindly producing wrong results
• produce a multi-polygon with two parts, one for each side of the antimeridian
• add 360 to east so you preserve the west < east assumption

[soxofaan]

FYI: also look at comparable utility in openeo_driver:
https://github.com/Open-EO/openeo-python-driver/blob/b7d0f7bea15a2c4bec03ee71f11c416854bc775e/openeo_driver/util/geometry.py#L590-L617

[VincentVerelst]

Comitted something that uses the exact same antimeridian crossing logic as the python driver and a split between as_polygon and as_geometry