Dateline

[EmileSonneveld]

The issue was an intersection calculation losing a lot of precision due to reprojecting and back.
Now the intersection between the feature and the requested extent is calculated in the target extent crs.

This made that some tests now load a smaller piece of the feature, on some places {FloatConstantNoDataArrayTile@16026} ArrayTile(256,256,float32) became {PaddedTile@15829} PaddedTile(ArrayTile(140,122,float32),17,134,256,256)

[jdries]

Can you also add a test where the feature extent is outside of the valid bounds of target CRS? For instance, a feature with global extent, and target extent being some utm zone.
I think this is the reason for going via EPSG:4326 to compute the intersection safely.

[EmileSonneveld]

Added a test for feature in LatLng and target extent in UTM.
Had to change the code too. This comment describes the change:

We convert both extents to a common CRS before taking the intersection.
If one of the CRSes can cover the whole world (non-UTM), this will be used as common CRS.
We give priority to use the target CRS as common one, because the intersection will be converted to it anyway

[EmileSonneveld]

There where already many cases where 2 different UTM extentds where used. Confirmed by logging

[jdries]

it now assumes that utm is the only projection that has this issue.
EPSG:3035 is another example that we work with a lot.
It could be that the valid area of a crs is in fact available, maybe we can check on that.