Revise global extent computation & alignment

Global extent alignment is not quite fine yet, consider a few things:

for all load_stac/load_collection cases, serialize queried products to an itemcollection
use the actually involved assets in a load collection to determine alignment and collection resolution
a masking operation should not affect global extent of whatever it masks??
the crs/alignment of global extent should depend on which input cube is preserved rather than blindly merging everything together

Related:
Open-EO/openeo-geopyspark-driver#1193

Note that if we build such a static stac collection or itemcollection, we could also improve the 'derived-from' links to rather point to this static catalog, reducing the dependency on the actual on line catalog?
See: Open-EO/openeo-geopyspark-driver#824

Related: Open-EO/openeo-geotrellis-extensions#120

Tiles in geotrellis follow tile layout = pixel grid

Pixel grid has to be equal to the pixel grid of load_stac/load_collection. But we have to know this pixel grid from the STAC metadata.

Currently this is hacky:

via datacube extension

We want this on:

asset level (properties of projection extension)

Take union of all grids (everything before resample_spatial), this gives global_extent.

Pass to Scala via DataCubeParameters in load_stac.

The current system will work for some collections.
We want to check every collection:

S2 L2A UTM (Multi-resolution assets) = more advanced
- Test: if only 60m bands then it should be different alignment than 10m bands included
  - Some tests already exists (see openeo-collection-tests)
Copernicus Globalland (1km products)

Normally no changes are required in the dry_run, except for:

                extent = _align_extent(extent,collection_id[1][0],env)

Leave mask feature for last.

*for all load_stac/load_collection cases, serialize queried products to an itemcollection

If you have the list of items that you will actually use, rather than the entire collection metadata
https://github.com/Open-EO/openeo-geopyspark-driver/blob/bfbcf9a4391009c8f20f05d10584ba33a8a4a7ea/openeogeotrellis/load_stac.py#L388
the crs/alignment of global extent should depend on which input cube is preserved rather than blindly merging everything together
- In first implementation, we have union of everything. But if you have resample_spatial, mask, ... then you h
  ave to make the correct decisions about which cube to preserve
- resample_spatial: resample parameters are pushed down or not
  - Depending on case you need to inherit global_extent or not.
- several other cases, there are some in the unit tests (diamond shapes, ...)
  - check if new implementation can handle these

Annotate some global_extent and _extract_load_parameters logic

as far as I understand there is a lot of overlap or even duplication with this ticket

load_stac: improved alignment to native grid openeo-geopyspark-driver#1299

WIP "post_dry_run" concept for #406

Stick to None as default `temporal_extent` in `_extract_load_parameters`

extract spatiotemporal_extent concern from construct_item_collection

Fully eliminate load_params from construct_item_collection

extract spatiotemporal_extent concern from construct_item_collection

Fully eliminate load_params from construct_item_collection

Start using global_extent_aligned from env

Remove weird "layer native extent" override

Allow-list new "global_extent" EvalEnv key

Fixup use case of load_stac without spatial extent

PR #1460 Changelog entry and version bump

Handle global extent from stac based load_collection through load_stac

support auto-UTM in post_dry_run._buffer_extent

Handle global extent from stac based load_collection through load_stac

post_dry_run global_extent: fix handling of resample_spatial with exp…

As noted, there is a lot of overlap here with Open-EO/openeo-geopyspark-driver#1299 and most of this has been covered already. I tried to identify the left-overs and created separate tickets, to make it more manageable to tackle:

Navigation Menu

Repository navigation

Revise global extent computation & alignment #406

66 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Revise global extent computation & alignment #406

Description

Activity

jdries commented on May 21, 2025

jdries commented on May 21, 2025

JeroenVerstraelen commented on Nov 17, 2025

soxofaan commented on Nov 24, 2025

66 remaining items

soxofaan commented on Mar 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions