Cloud-Native GIS: What Analysts Need to Know About COGs and STAC

For most of the history of remote sensing, working with satellite imagery meant downloading it first — pull the full scene to local disk, load it into your GIS software, then do the analysis. That workflow made sense when datasets were smaller and internet infrastructure was slower. It makes a lot less sense now, when a single Sentinel-2 tile can be over a gigabyte and you often only need a small window of it. Cloud-native geospatial formats exist specifically to fix that mismatch, and two of them — COG and STAC — have become close to the default way modern imagery is stored and discovered.

COG: Same File, Smarter Internal Layout

A Cloud Optimized GeoTIFF isn't a new file format in the way PNG is different from JPEG. It's a regular GeoTIFF with its internal structure rearranged specifically so a client can request just the pixels it needs over HTTP, rather than downloading the entire file. It does this through internal tiling and pre-built overviews (lower-resolution versions of the same image baked into the file), combined with HTTP range requests — a standard web technique that lets a client ask a server for a specific byte range of a file instead of the whole thing.

The practical effect: a web map that only needs to show what's visible on screen, or a notebook that only needs a small area of interest, can fetch just that portion of a COG sitting in ordinary cloud storage — no specialized server required, no full download. That's why COGs work well both for interactive browser-based mapping and for batch processing pipelines that need to work through thousands of scenes without staging them all locally first.

STAC: How You Find the Right COG in the First Place

COG solves efficient access. It doesn't solve discovery — knowing which files exist, where they are, and whether they actually cover your area and dates of interest. That's what the SpatioTemporal Asset Catalog specification handles. A STAC catalog is built from JSON metadata describing a dataset's spatial extent, time range, and available assets (bands, thumbnails, derived products), structured so it's both human-browsable and machine-queryable through a standard API.

In practice, the workflow looks like this: you query a STAC API for imagery matching your area and date range, get back a list of STAC Items (each one pointing to the actual COG files via URLs), and then stream just the COG data you need for visualization or analysis. No bulk downloads, no manual browsing through a data provider's file structure trying to guess what's relevant.

This combination is genuinely widespread now — AWS hosts the full Sentinel-2 archive as COGs with a public STAC API (Earth-search) sitting in front of it, and this pattern — COG for storage, STAC for discovery — has become close to the standard architecture behind most modern satellite data platforms, including the ones powering interactive web-based imagery viewers.

What This Actually Changes for Your Workflow

If you're used to a "download first, analyze second" habit, a few concrete shifts are worth adopting:

• Query before you fetch. Use a STAC API (through a Python client like pystac-client, or a browser-based STAC Browser) to find exactly which scenes match your area and date range before pulling any pixel data — this alone can save enormous amounts of unnecessary transfer.

• Read windows, not whole files. Libraries like rasterio and rioxarray can open a COG and read just a bounding box or a specific resolution level, rather than loading the full image into memory.

• Prefer tools built around this pattern. Google Earth Engine, TiTiler-based map servers, and most modern cloud GIS platforms are already built assuming COG + STAC as the underlying data layer — which means you often get this efficiency for free just by using them, without managing the access pattern yourself.

Where the Rest of the Ecosystem Is Heading

COG and STAC are the two most established pieces, but they're part of a broader shift, not the whole story. GeoParquet is emerging as the equivalent pattern for vector data — cloud-efficient, columnar access instead of downloading a full shapefile. Zarr and the newer GeoZarr specification aim to do something similar for multi-dimensional data cubes (time, x, y, multiple bands at once), which COG wasn't really designed for. None of these are fully mature standards yet the way COG is, but the direction is consistent: geospatial data formats are being redesigned around cloud storage and partial access as the default, not the exception.

Why This Matters If You're Studying or Working in RS & GIS

The honest reason this belongs on a "what analysts need to know" list rather than just a "what's technically interesting" one: understanding COG and STAC changes what's actually feasible for you to work on. Projects that used to require significant local storage and a beefy workstation — time-series analysis across a whole region, monitoring over years of imagery — become realistic on a laptop once you're not downloading everything up front. If you're a student building portfolio projects, this is also a practical skill gap worth closing early: knowing how to query a STAC API and read COG windows efficiently is quickly becoming as fundamental as knowing how to open a shapefile used to be.

Working with a specific STAC catalog or COG-based pipeline? I'd like to hear what you're building — reach out on the Contact page.