[gdal-dev] Can valid cloud-optimized geotiffs have non-sequential tile ordering?

[Scott Henderson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250107/84f3a9c0/attachment.htm>