GDAL2Tiles.py erroneously crops raster

[keltonhalbert]

Expected behavior and actual behavior.

I'm using gdal2tiles.py to tile an image that was reprojected using gdalwarp, and the resulting tiled output crops the southern border of the image by a significant portion. I'm not sure if this is intended or not, but I couldn't find any documentation on what's happening, nor could I find similar bug reports. Something tells me it may be some sort of behind the scenes optimization given the large swaths of transparent/empty data... but I'd like to figure out how to get around this, if possible.

The original raster:

The resulting tiled output:

Steps to reproduce the problem.

Here is a link to the original raster Here is a link to the little web viewer it spits out

The command I used was gdal2tiles.py -r near -z 0-7 MRMS_MergedReflectivityAtLowestAltitude_00.50_20210519-191441reprojected.tif ./test

Operating system

I'm using CentOS 8

GDAL version and provenance

I'm using GDAL 3.2.0

[jratike80]

There has been other problems connected somehow with the use of parameter -z 0-x. Could you have a try with default zoom levels?

[keltonhalbert]

The result withholding the zoom levels results in the same output

./gdal2tiles.py -r near MRMS_MergedReflectivityAtLowestAltitude_00.50_20210519-191441reprojected.tif ./test_nozoom

[jratike80]

Ok, so it is something else than in https://github.com/OSGeo/gdal/issues/1980.

[jratike80]

Same cropped result for me on Windows with GDAL 3.1.4.

[EvertEt]

Confirmed with included viewers on GDAL 3.2.0 on MacOS. Could you try feeding gdal2tiles the unreprojected file?

[keltonhalbert]

Okay, so passing through the original GeoTIFF (in EPSG:4326/latlon) appears to avoid the cropping issue. I didn't go through colorizing in this step but the point should get across. Here's the map viewer.

In the examples above, my gdalwarp command looks like the following... gdalwarp -t_srs EPSG:3857 -ts 7000 3500 unrpojected.tif reprojected.tif

So, obviously gdal2tiles is doing some sort of retrojecting under the hood... what gives with the cropping when the reporjecting is done beforehand? Clearly this is a bug and not an intended result.

[keltonhalbert]

Okay, so fun little plot twist here! If I remove -ts from my gdalwarp command, gdal2tiles successfully tiles the image without cropping.

It looks like if I supply the argument -tr instead, then gdal2tiles still renders just fine as well. It seems to be something very specific to using -ts with gdalwarp and then passing to gdal2tiles.

[keltonhalbert]

Anyone have any insight into why gdal2tiles fails only with specific arguments passed to gdalwarp? Or should I just close this issue since there's a workaround?

[jratike80]

The issue is not resolved but it is not most easy to investigate, and because there is a workaround it is not of the highest priority. Still no hurry to close it.

Gdal2tiles cannot know what parameters have been passed to gdalwarp but you are right that there must be something special in the image MRMS_MergedReflectivityAtLowestAltitude_00.50_20210519-191441reprojected.tif that is produced with that exact command. If you happen to have some time you could try if the error happens with other sizes, like -ts 7000 4500. A tiled GeoTIFF is usually better for GIS usage than striped one, so you could also have a try with -co tiled=yes.