[gdal-dev] Variable Tile Sizes
cfis at savagexi.com
cfis at savagexi.com
Thu Mar 7 19:11:35 PST 2024
We have a custom tiling scheme (tilematrixset) for satellite imagery that varies tile widths as they move closer/farther from the equator. We do this for speed/efficiency reasons and the amount of error introduced is minimal over short distances and doesn't impat running CV algorithms. However, this means that our tiles may differ in width by a pixel for a paritcular satellite image (we tile the images).
Using gdalbuildvirt to combine the tiles back into a single image works fine.
However, we would like to serve them using the OGC tile api. And that doesn't work, due to this error:
>
> ERROR 1: GDALWMS: Incorrect size 983 x 1232 of downloaded block, expected 982 x 1232, max 982 x 1232.ERROR 1: GDALWMS: ReadBlockFromFile (0.0.0.0:5500/ogcapi/collections/1050010019917900---s---WV02---wv02---NA---NA/map/tiles/C1232_180_180/0/0/1.tif) failed.ERROR 1: GDAL_WMS>, band 1: IReadBlock failed at X offset 0, Y offset 0: GDALWMS: ReadBlockFromFile (0.0.0.0:5500/ogcapi/collections/1050010019917900---s---WV02---wv02---NA---NA/map/tiles/C1232_180_180/0/0/1.tif) failed.
>
The code that causes this is:
>
> **
> */* expected size */*const int esx = **MIN**(MAX(0, (x + 1) * nBlockXSize), nRasterXSize) -
>
> **MIN**(MAX(0, x * nBlockXSize), nRasterXSize);
>
> const int esy = **MIN**(MAX(0, (y + 1) * nBlockYSize), nRasterYSize) -
>
> **MIN**(MAX(0, y * nBlockYSize), nRasterYSize);
>
> int sx = ds->GetRasterXSize();
>
> int sy = ds->GetRasterYSize();
>
> */* Allow bigger than expected so pre-tiled constant size images work on** * corners */*
> if ((sx > nBlockXSize) || (sy > nBlockYSize) || (sx < esx) || (sy < esy)){ CPLError(CE_Failure, CPLE_AppDefined, "GDALWMS: Incorrect size %d x %d of downloaded block, " "expected %d x %d, max %d x %d.", sx, sy, esx, esy, nBlockXSize, nBlockYSize); ret = CE_Failure;}
>
I was hoping that the comment about bigger than expected size images would work, but from the error message above it does not.
So I expect the answer is no, but is there any way we could work around, loosen or disable this restriction? Or some other idea on how to make this work?
Thanks,
Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/d6d4b777/attachment.htm>
More information about the gdal-dev
mailing list