COGs

A cloud-optimized GeoTIFF is an ordinary GeoTIFF with its bytes arranged so that a reader can fetch just the part it needs over the network, without downloading the whole file first. That single idea is what makes it the default storage format for cloud-native imagery. The pixels in a digital image do not change; what changes is the layout — how the file is tiled internally, what reduced-resolution copies it carries, and how its metadata is positioned — so that reading a small window of a large scene costs a small, predictable number of requests instead of a full transfer. This note takes the engineering angle on why that layout matters, what the tradeoffs are, and how COGs sit alongside catalogs, mosaics, and processing systems. It is not a GDAL command tutorial; the durable knowledge is the reasoning, not any one tool’s flags.

What the layout actually buys you

Three properties, working together, turn a plain raster into a cloud-optimized one. The first is internal tiling: instead of storing pixels row by row across the whole image, a COG stores them in fixed square blocks — commonly 256×256 or 512×512 — so the pixels for any small map region are contiguous in the file. The second is overviews: pre-computed, downsampled copies of the image baked into the same file, so a viewer zoomed out to the whole scene can read a coarse overview rather than crunching every full-resolution pixel. The third is a header laid out for range reads: the internal directory that says where each tile and overview lives is written up front, so a client can read the metadata, learn the byte offsets it wants, and then ask storage for exactly those ranges. The enabling mechanism underneath all three is the HTTP range request — the ability to fetch bytes m through n of an object rather than the whole thing — which object stores support natively. Put together, these mean a map tile server, a notebook, an API, or a batch job can open a multi-gigabyte scene, read its header, and pull only the handful of tiles covering its area of interest at the resolution it needs. The file can be enormous; the read stays cheap.

Why partial reads change the economics

The reason this matters is that most geospatial work touches a small slice of any given scene at a time. An interactive map needs one tile pyramid level over one viewport; a notebook exploring a study area needs a few square kilometers out of a full Sentinel or Landsat frame; an API answering a point query needs a single tile. Without COGs, each of those forces a whole-file download — bandwidth, storage churn, and latency all scale with the size of the archive rather than the size of the question. With COGs, they scale with the size of the answer. That is the shift that makes it practical to keep petabytes of imagery in object storage and read it in place, which is the foundation of the cloud-native geospatial architecture. It also composes well with discovery: a STAC item points at COG assets, so a search can select the right scenes and a consumer can then range-read only the windows it wants from those exact files, never staging a local copy of the full archive. Overviews matter here too — matching the overview level to the display resolution means a zoomed-out view reads far fewer bytes than the native pixels would require.

Storage and compression tradeoffs

The layout choices that make a COG are not free, and they trade cost, latency, and compatibility against each other. Tile size is the first lever: small tiles mean more, smaller reads and finer granularity but more per-request overhead; large tiles mean fewer requests but more wasted bytes when you only wanted a corner of one. The common 256 or 512 blocks are a pragmatic middle. Compression is the second: lossless schemes like DEFLATE or LZW keep every value exact, which matters for analytical bands where the pixel is the measurement, while methods tuned for imagery can shrink files much further at the cost of exactness or of reader support. The honest caveat is that not every downstream tool reads every compression codec, so an aggressive choice can save storage while quietly making the data harder to consume — compatibility is part of the cost. Overviews add their own tradeoff: they inflate file size and must be regenerated when the underlying pixels change, in exchange for fast zoomed-out reads. And because a range read is one or more network round trips, latency depends on how many requests a typical access needs; a good layout answers the common query in few reads, while a poorly tiled or overview-less file can turn one logical read into many. None of these has a universally right answer — they depend on whether the data is imagery for viewing or measurements for analysis, and on what will read it.

Validation, metadata, and lifecycle

Operating an archive of COGs is mostly about keeping them honestly cloud-optimized over time. Validation is the first discipline: a file can be a valid GeoTIFF and still not be cloud-optimized — missing overviews, untiled, or with its header in the wrong place — so archives check that new files actually meet the layout contract before publishing, because a subtly non-optimized file degrades every reader that assumed range reads would be cheap. Metadata must travel with the pixels: the coordinate reference system and geotransform that place the image in the world (the coordinate systems reasoning), the nodata value, the band descriptions, and the units. A COG carries these internally, which is what lets a consumer interpret the bytes correctly without a separate sidecar, and it is why catalog metadata and file metadata should agree rather than drift. Lifecycle is the last concern: reprocessing changes pixels and therefore invalidates overviews and statistics; storage tiers and retention affect how quickly a range read responds; and any change should preserve or clearly supersede the identifiers a catalog recorded, so a downstream result can still trace back to the file it used.

Where COGs fit

It helps to place COGs precisely in the stack rather than treat them as the whole story. They are the storage-and-access layer for raster: they hold the bytes and make partial reads efficient, and nothing more. Above them, catalogs describe and locate the files, and a mosaic — a virtual composite that stitches many COGs into one seamless surface — lets a consumer treat a tiled archive as a single canvas by reading the relevant window from whichever underlying COGs it overlaps, again through range reads rather than a merge step. Alongside them, distributed processing reads COG windows in parallel, so a large job is many independent cheap reads instead of one giant transfer, which is exactly what a raster processing pipeline depends on when it operates over full scene collections. Cloud archives and hosted platforms such as the Microsoft Planetary Computer expose their imagery as COGs precisely so that discovery, viewing, and processing can all read in place. The tools, codecs, and tile sizes vary; the invariant is the one worth remembering — arrange the bytes so the cost of a read matches the size of the question, and the rest of the cloud-native stack follows from there.