WindowError: Bounds and transform are inconsistent about rasterio HOT 7 CLOSED

Hello,

I am experiencing the same issue. Mosaicking sequential Sentinel-1 collections (same orbital path) raises this exception. I also had the same problem when trying to extract a subset on a single image (I got around this by warping the data first, to a north up orientation). Both cases the rely on windows.from_bounds() function and both fail here:

if (bottom - top) / transform.e < 0:
raise WindowError("Bounds and transform are inconsistent")

This must be a new check since both cases used to work fine on unwarped data about two years ago. I guess I will have to warp the two sequential images before mosaicking.

But I am trying to figure our exactly what this check is looking to accomplish. The numerator should always be negative. The denominator when positive, or zero should raise the exception but wouldn't fail if denominator is negative. My understanding is this particular parameter is related to the rotation of the image from north, the native image collection geometry from the satellite. So, this would seem to pass for SAR passes in one direction (say ascending for example) but not the other (descending pass). Am I missing something?

from rasterio.

@iamtekson thanks for writing in. First of all, merge is intended to work on datasets with a common coordinate reference system and which have basically the same orientation. In your debugging info, I see a red flag: the second set of bounds look like they are "north up", with dst_n > dst_s, while the other two look like they are flipped, with south > north.

1. int_w, int_s, int_e, int_n 83.3366190762396 27.544951725428476 83.35961594751306 27.521954854155016
2. dst_w, dst_s, dst_e, dst_n 83.3366190762396 27.475961111608097 83.49759717515383 27.682932953069233
3. src_w, src_s, src_e, src_n 83.3366190762396 27.544951725428476 83.35961594751306 27.521954854155016

These cannot be merged as they are. Can you check their CRS and geo transform matrices, perhaps with a different tool like gdalinfo, to confirm that they have the same orientation?

from rasterio.

Hi @sgillies, Sorry for being late. I investigated the issue and found that the the issue was with float64 bit raster in geotile issue #59. When I checked, I found that the mosaic function has an issue with the float64 bit raster.

But another interesting thing is that when I checked the dtype in QGIS, the raster dtype was float64, but when I checked with rasterio and ArcGIS pro, the dtype was float32. What might be the cause?

from rasterio.

I am getting the same issue when using clip_box from rioxarray. I am passing left, bottom, right, top coordinates in the native CRS of the xarray Dataset I want to clip, and the code fails in the same spot noted above in rasterio/windows.py (lines 323-324). I'm using rasterio v1.3.8.

from rasterio.

@pmallas @rpalomaki I think you've got slightly different issues from the original reporter, even if you're seeing the same error message. Some code that reproduces the problem would be very useful.

from rasterio.

from rasterio.

from rasterio.