cogeotiff/rio-cogeo

--web-optimized option creates image with incorrect bounds

Closed this issue · 6 comments

not sure if this is related to #123 but when using the --web-optimized option the output has a larger bounding box than the input.

tile.tiff tile.tiff.zip

rio cogeo create --cog-profile deflate --dtype float32 --overview-resampling bilinear --web-optimized --resampling bilinear tile.tiff 1.tiff

2

rio cogeo create --cog-profile deflate --dtype float32 --overview-resampling bilinear --resampling bilinear tile.tiff 2.tiff

1

The input tile.tiff has the bounds of the second screenshot, so the first command with --web-optimized creates an incorrect output.

although I guess with cogeo support coming in gdal 3.1 I might end up swapping to gdal, but just annoying that it hasn't been released yet.

Just tested with gdal latest docker using the COG driver and I don't see the issue even using -co TILING_SCHEME=GoogleMapsCompatible, so I might use gdal instead.

@andrewharvey thanke for the issue I'll check later today.

Yeah GDAL3.1 and the new COG driver might be a better solution and it should be released next month.

Hey @andrewharvey sorry it took me more than a month 😬

rio-cogeo seems to work as expected because your file cut the z13 tiles on the top left

$ rio bounds tile.tiff| supermercado burn 13 | mercantile shapes > z13.geojson

This might just be a precision issue because it seems your file is shifted by 7m to the west and 4m to the north when comparing to the mercantile Tile (given by mercantile)

hi @vincentsarago

Thanks for looking into this, you're right when I zoom right in I can see the precision issue and I now understand why it's needing to fill in these other tiles when using web-optimized.