I’m accustomed to GeoTiff files having row-wise sequential layout of image tiles (and I was under the impression that GDAL assumes this for merging range requests)?
But I recently noticed a lot of excess GET requests working with SRTM data that passes COG validation scripts: > https://opentopography.s3.sdsc.edu/raster/SRTM_GL1/SRTM_GL1_srtm/N59W102.tif These files seem to have TileOffsets scattered about (for example here is excerpt from tiffdump: TileOffsets (324) LONG (4) 64<2269213 2409502 3485315 2716342 …) I believe this odd layout is causing the many GET requests to access this data, for example: CPL_DEBUG=ON gdal_translate -srcwin 0 0 1024 512 /vsicurl/https://opentopography.s3.sdsc.edu/raster/SRTM_GL1/SRTM_GL1_srtm/N59W102.tif test.tif Since a key aspect of COGs is efficient network access, shouldn’t this file not be considered a COG? ------------------------------ Scott Henderson Research Scientist, Earth & Space Sciences Data Science Fellow, eScience Institute Johnson Hall 251 University of Washington http://scottyhq.github.io
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
