Alan D. Snow

This looks really nice 👍. Something to watch out for is to check if an error was raised inside of GDAL and handled internally before the function returns successfully.

I tested this out wrapping https://github.com/rasterio/rasterio/issues/2353#issuecomment-1160420552 `with stack_errors():`. Unfortunately, this happened: ``` Traceback (most recent call last): File "/home/snowal/scripts/rasterio/bounds.py", line 26, in print(transform_bounds(dst.crs, "epsg:4326", *dst.bounds)) File "/home/snowal/scripts/rasterio/rasterio/warp.py", line 151, in...

https://github.com/rasterio/rasterio/issues/2353#issuecomment-1160618200 ``` Looks like transform_bounds is leaving an error on GDAL's error stack. ```

> @snowman2 from your perspective, is there anything unresolved here? I think that the main risk of this implementation is that code will now error out and fail when it...

One thing @scottyhq mentioned in the previous discussion is that `gdalwarp` transformed the elevation values: ``` gdalwarp -s_srs EPSG:4326+3855 -t_srs EPSG:7661 $INPUT $OUTPUT ```

> wasn't quite sure how to verify command line gdal and dependencies match the rasterio wheels With `rasterio==1.3a4`: `rio --show-versions` or `python -c "import rasterio; rasterio.show_versions()"`

> I observe the same behavior documented above with rasterio=1.3a4, but it seems that brings GDAL3.4.2 and PROJ8.2.1 whereas the GDAL3.4.2 docker containers or GDAL from conda-forge bring PROJ 9.0.0....

> I tried the following with rasterio 1.3b1 (perhaps this deserves a separate issue or discussion thread): > > ``` > docker run --rm -it osgeo/gdal:ubuntu-small-3.5.0 bash > apt install...

I wonder if there is any connection with this fix #2512?

Wonder if this is related? https://github.com/conda-forge/rasterio-feedstock/issues/239