The platform team is deciding whether the land-cover and Sentinel rasters can be served straight from object storage through a tile server, or need pre-cut tiles. The argument for serving in place is that a cloud-optimised GeoTIFF lets one map tile be answered with a few range requests. The lead wants the structure of the delivered files measured — how many internal tiles, how many overview levels, how many bytes — so the decision rests on the files and not on the format's reputation.
From the land-cover and the Sentinel-2 files, report:
landcover_tiles_full_res — the number of internal tiles in the land-cover file's full-resolution level (block size from the file; partial edge tiles count)landcover_overview_levels — how many overview levels the land-cover file carriessentinel_tiles_full_res — the same tile count for the Sentinel-2 filesentinel_bytes — the Sentinel-2 file's size in bytes, as deliveredA tile server answering a 256 px map tile at full resolution reads a few internal tiles by byte range; at lower zooms it reads the overview instead. The overview count is what makes the small-scale map cheap; the internal tile count is what the full-resolution request fans out over.
These are where the teaching is. Read them twice.
Serving imagery straight from object storage rests entirely on the file's internal structure, and reading that structure is how a platform team decides it can.
Work the problem in whatever tool you like, then enter the answers here.
landcover_tiles_full_reslandcover_overview_levelssentinel_tiles_full_ressentinel_bytes4 scored, 0 informational
Land-cover internal tiles at full resolution
33%Land-cover overview levels
22%Sentinel-2 internal tiles at full resolution
22%Sentinel-2 file size
22%