Improve calculate_default_transform/aligned_target interaction about rasterio HOT 5 OPEN

After more reflection, a new (attrs) class would eliminate confusion between elements of the extent triple. Which is a real problem and solving this problem is ~half the purpose of attrs.

src_extent = Extent(width=src_width, height=src_height, transform=src_transform)

dst_extent = rasterio.warp.align_extent(rasterio.warp.get_warped_extent(
    "EPSG:32618",
    "OGC:CRS84",
    extent=src_extent,
    ),
    0.002
)

The class would allow fast point-in-raster tests, too.

extent = Extent(width=width, height=height, transform=transform)
col, row = ~extent.transform * (x, y)
0 <= col <= extent.width and 0 <= row <= extent.height

@groutr I think that an Extent class might complement BoundingBox well and resolve the ambiguity between the two concepts that has been troubling us for some time. BoundingBox would remain 4 values (xmin, ymin, xmax, ymax) that describe an unrotated rectangle in space. Extent would describe a rectangle in space that could have any rotation, like the spatial footprint of a raster (data and nodata combined). #2901 could be simplified by letting the bounding box test be ignorant of rotation or north-south up orientation.

@snowman2 @vincentsarago any comments or questions?

from rasterio.

@sgillies The Extent idea seems interesting. I want to think on it a little more, but my initial thought is what if rasterio went a step further and superseded BoundingBox with Extent? transform.array_bounds could be used to compute the bounding box coordinates where needed.

from rasterio.

@vincentsarago Rasterio's raison d'être is to be the best Python API for using classic raster data. Not in terms of absolute performance or number of features or format support (it's too hard to keep up with GDAL anyway), but in terms of clarity and usability. Rasterio is supposed to allow Python programmers to think less about small insignificant GDAL details. I think it's the most important thing for the project. Our North Star, to be cliché.

Right now we have ambiguity about whether the bounding box is the corners points or the minimum and maximum of the corners, and that's pretty terrible. And then we have a lot of functions that take transform, height, and width as parameters or return the same three things. But in varying order! This is also terrible, entirely of my making, and something that's been bugging me for a long time. An Extent would be super useful to me and it allows new users to think less about little details.

A better name may exist, and it could wait for a 1.5.0 release. 1.4.0 has been delayed long enough already 😅

from rasterio.

WoW I didn't knew about aligned_target 🤯 (I needed this couple weeks ago, and had to write it from scratch 😅 )

I fear there will be confusion between Extent and BoundingBox, and event if documented people might still use one or the other in bad ways. Maybe WarpExtent might be less confusing 🤷‍♂️

rasterio.warp.calculate_default_transform has been there for a long time so I guess users are use to it (I am 😅) so I'm not sure to really get why we need to change it

Maybe another solution would be to add an option in calculate_default_transform to align with a target resolution 🤷‍♂️

edit: just looking at https://github.com/search?q=calculate_default_transform&type=code there are a lot of user of this function. I agree that with 1.4 we can break things, but maybe we break things that are not working well first 😅

from rasterio.

I really like these ideas! In my own code I have Grid class that contains width, height, transform, and crs. I have a reproject method that calls calculate_default_transform and returns a new Grid. I also have a snap_to method that will align the Grid with particular point, not necessarily the origin. It might be nice if align_extent would let you align with an arbitrary point.

If we're packaging height, width and transform together in an Extent class, can we make them unpackable?

from rasterio.