Investigate weird `tolerance condition error` issue when working with GOES dataset.

This was first reported in https://github.com/developmentseed/titiler/issues/413#issuecomment-985319883

Their is a really weird behaviour when calling the .colorinterp property of the rasterio object within the COGReader:

from rio_tiler.io import COGReader
with COGReader("http://static2.skysight.io/demo2.tiff") as cog:
    print(cog.dataset.colorinterp)
---------------------------------------------------------------------------
CPLE_AppDefinedError                      Traceback (most recent call last)
<ipython-input-4-be6c69e3f1c3> in <module>
      1 with COGReader("http://static2.skysight.io/demo2.tiff") as cog:
----> 2     print(cog.dataset.colorinterp)
      3 

rasterio/rasterio/_base.pyx in rasterio._base.DatasetBase.colorinterp.__get__()

rasterio/rasterio/_err.pyx in rasterio._err.exc_wrap_int()

CPLE_AppDefinedError: tolerance condition error

Interestingly it’s not related to the .colorinterp property but it all goes back to the call to get_zooms https://github.com/cogeotiff/rio-tiler/blob/master/rio_tiler/io/cogeo.py#L130-L131 because when we set the zooms we then get the normal behaviour (get_zooms performs Coordinate transformation from dataset CRS to TMS CRS, so by setting the zooms in the Object init we don’t do any coordinate transformation).

with COGReader("http://static2.skysight.io/demo2.tiff", minzoom=0, maxzoom=10) as cog:
    print(cog.dataset.colorinterp)
(<ColorInterp.red: 3>, <ColorInterp.green: 4>, <ColorInterp.blue: 5>)

💥 It’s get even weirder. If we just use rasterio to open a dataset then put it in a VRT, we can see that it exit the VRT just fine (prints i'm outside the VRT block) but we still get CPLE_AppDefinedError: tolerance condition error

with rasterio.open("http://static2.skysight.io/demo2.tiff") as src:
    print(src.colorinterp)
    with WarpedVRT(src, dst_crs="epsg:3857") as vrt:
        print(vrt.bounds)  # print bounds to confirm, VRT worked
        pass

    print("i'm outside the VRT code")
    print(src.colorinterp)


(<ColorInterp.red: 3>, <ColorInterp.green: 4>, <ColorInterp.blue: 5>)
BoundingBox(left=-5434894.885056, bottom=-5434894.885056, right=5434894.885056, top=5434894.885056)
i'm outside the VRT code

---------------------------------------------------------------------------
CPLE_AppDefinedError                      Traceback (most recent call last)
<ipython-input-5-fb35a7cd9fa3> in <module>
      5 
      6     print("i'm outside the VRT code")
----> 7     print(src.colorinterp)
      8 

rasterio/rasterio/_base.pyx in rasterio._base.DatasetBase.colorinterp.__get__()
rasterio/rasterio/_err.pyx in rasterio._err.exc_wrap_int()

CPLE_AppDefinedError: tolerance condition error

cc @sgillies, I’ll continue to investigate, but to me it’s seems kinda a race condition or a GDAL error that could be ignored but still surface

GDAL warp prints the same error but still succeed to create the VRT

$ gdalwarp /vsicurl/http://static2.skysight.io/demo2.tiff demo.vrt -of VRT -t_srs epsg:3857
ERROR 1: tolerance condition error
ERROR 1: tolerance condition error
ERROR 1: tolerance condition error
ERROR 1: tolerance condition error
Creating output file that is 25409P x 17200L.
Processing /vsicurl/http://static2.skysight.io/demo2.tiff [1/1] : 0Using internal nodata values (e.g. 0) for image /vsicurl/http://static2.skysight.io/demo2.tiff.
Copying nodata values from source /vsicurl/http://static2.skysight.io/demo2.tiff to destination demo.vrt.
...10...20...30...40...50...60...70...80...90...100 - done.

cc @rouault (might be of interest)

[vincentsarago]

Good news, this will be fixed in next rasterio release 🥳, I’m going to close here because there is nothing to change in rio-tiler 🙏

[malaretv]

@vincentsarago My case is various lunar datasets (in eqc and polar stereographic) trying to output tiles in a polar-rotated TMS (+proj=ob_tran +o_proj=eqc +o_lon_p=180 +o_lat_p=0 ...). So the tolerance condition errors i’m getting in tile_exists() are almost certainly warranted, just need to be handled.