What do processing levels L0 to L4 mean?

L0 is raw instrument data, L1 is radiometrically/geometrically corrected radiance, L2 is geophysical variables (e.g. surface reflectance), L3 is gridded/composited products, and L4 is modelled or fused outputs. Most analysts start at L2 surface reflectance.

What is analysis-ready data (ARD)?

ARD is satellite data pre-processed to surface reflectance, geometrically registered to a fixed grid, and packaged with per-pixel quality and cloud masks, so it can be stacked across dates without per-scene correction. Landsat and Sentinel-2 both offer ARD.

Why are COG and STAC the modern defaults?

Cloud-Optimized GeoTIFF lets clients read only the bytes they need over HTTP via internal tiling and overviews; STAC is a JSON standard for describing and searching those assets. Together they enable querying petabyte archives without bulk download.

Download, API, or tiles — which access method?

Download suits repeated heavy analysis on fixed data; an OGC API or STAC search suits dynamic queries; tile services (XYZ, WMTS, vector tiles) suit fast map display. Match the method to whether you need pixels, features, or just a picture.

Earth Data Products Explained: Levels & Formats

Short answer

An "Earth data product" is raw sensor measurement that has been processed, corrected, gridded, and packaged so it answers a defined question. The two axes that define any product are its processing level (how far it has been transformed from raw signal, L0 through L4) and its packaging (the format, metadata, and access method through which you reach it). Knowing where a product sits on both axes tells you what you can do with it and what corrections you still owe.

This article maps those axes — levels, analysis-ready data, modern cloud formats, and access patterns — so you can pick the right product instead of downloading the wrong one and re-deriving work that already exists.

Processing levels: L0 to L4

NASA's EOSDIS scheme, widely adopted across agencies, classifies products by how much processing they have received.

Level 0 — raw instrument data at full resolution, communications artefacts removed. Almost no one outside calibration teams uses L0.
Level 1 — reconstructed, time-referenced, radiometrically calibrated. L1B carries calibrated radiance; L1C (Sentinel-2) and L1T (Landsat) add orthorectification and a map projection. You get top-of-atmosphere reflectance.
Level 2 — derived geophysical variables at the same resolution: surface reflectance after atmospheric correction (Sentinel-2 L2A, Landsat Collection 2 L2SP), land surface temperature, sea surface temperature. This is where most analysis begins.
Level 3 — variables mapped onto a uniform space-time grid, usually composited to fill gaps and remove clouds (e.g. MODIS 16-day NDVI, monthly composites).
Level 4 — model output or fused products: data assimilated with a model or combined across sensors (e.g. evapotranspiration, gridded climate reanalysis).

The practical rule: the higher the level, the less per-scene correction you do, but the more processing assumptions are baked in that you can no longer see or change. L2 surface reflectance is the usual sweet spot — corrected enough to compare across dates, raw enough to control your own indices and compositing.

Atmospheric correction and why it matters

L1 top-of-atmosphere reflectance includes the atmosphere's own scattering and absorption, which vary by date, sun angle, and aerosol load. Computing NDVI from two TOA scenes acquired weeks apart can show a "change" that is purely atmospheric. L2 surface reflectance (produced by algorithms such as Sen2Cor for Sentinel-2 or LaSRC for Landsat) removes that, which is why time-series work should start at L2, not L1.

Scene, tile, and analysis-ready data

Sensors deliver scenes — the footprint of one acquisition (a Landsat scene is ~185 km wide). Scenes overlap, have ragged edges, and are corrected independently, which makes stacking them across dates fiddly.

Analysis-Ready Data (ARD) fixes this. The data is corrected to surface reflectance, reprojected onto a fixed tiling grid (Sentinel-2 uses the MGRS 100 km grid; Landsat ARD uses a regional Albers grid), and shipped with per-pixel quality assessment and cloud/shadow masks. Because every date lands on the same grid, you can build a temporal stack without per-scene reprojection. The CEOS CARD4L specification defines what qualifies as ARD.

Use the QA band rigorously. A pixel flagged as cloud, cirrus, or shadow must be masked before you compute any index, or your statistics inherit the contamination.

Modern packaging: COG, STAC, and Zarr

Three standards now dominate cloud-native Earth data.

Cloud-Optimized GeoTIFF (COG) is a regular GeoTIFF with internal tiling and overviews arranged so an HTTP client can issue range requests and read only the window and resolution it needs. You can render a continental overview or pull one field's pixels from a 2 GB file without downloading it. Convert with GDAL: gdal_translate in.tif out.tif -of COG -co COMPRESS=DEFLATE.
SpatioTemporal Asset Catalog (STAC) is a JSON specification describing geospatial assets — each Item has geometry, datetime, and links to assets (the COGs). A STAC API lets you query "all Sentinel-2 L2A items over this polygon, this month, under 20% cloud" and get back asset URLs. It is the search layer over the cloud archive.
Zarr chunks N-dimensional arrays for parallel cloud access, the typical choice for large climate/ocean datacubes (time × variable × lat × lon).

A typical modern workflow never downloads a full archive: a STAC search returns COG URLs, and tools like rioxarray, stackstac, or Earth Engine read only the needed chunks.

Vector and derived product formats

Not every Earth data product is raster. For the vector and tabular outputs of analysis:

GeoPackage (.gpkg) — an OGC SQLite container holding vector layers, attributes, and even rasters in one portable file. The pragmatic default; replaces the shapefile's 10-character field names, 2 GB limit, and multi-file fragility.
GeoParquet — columnar, compressed, excellent for large feature tables and cloud analytics.
GeoJSON (RFC 7946) — text, web-friendly, fine for small layers; verbose and slow at scale. Note RFC 7946 mandates EPSG:4326.
Vector tiles (MVT) — pre-tiled features for fast interactive web maps.

Choosing an access method

Match the delivery to what you actually need from the data.

Need	Access pattern
Heavy repeated analysis on a fixed AOI	Download COGs / GeoPackage once
Dynamic queries over a large archive	STAC API search, or OGC API - Features for vector
Fast map display	XYZ/WMTS raster tiles or MVT vector tiles
Programmatic feature CRUD	OGC API - Features

OGC API - Features (the modern successor to WFS) exposes feature collections over a clean REST/JSON interface — GET /collections/{id}/items?bbox=... — and is well suited to publishing your derived vector products.

Worked example — a cloud-free NDVI composite without downloads

To produce a summer NDVI median for a watershed: query a Sentinel-2 L2A STAC API by the watershed bbox and date range with a cloud-cover filter; receive COG URLs for the red and NIR bands plus the scene-classification (SCL) mask. With stackstac/xarray, read only the watershed window, mask SCL classes for cloud/shadow/cirrus, compute (NIR − Red)/(NIR + Red) per scene, take the per-pixel median across dates, and write the result as a COG. No full scene was ever downloaded; only the relevant pixels traversed the network. Record the STAC collection, date range, cloud threshold, and mask classes in the output metadata so the composite is reproducible.

Common pitfalls and why they happen

Computing indices on L1 TOA data. Atmospheric variation masquerades as real change. Use L2 surface reflectance.
Ignoring the QA/cloud mask. Clouds and shadows skew every statistic; ARD ships masks precisely so you apply them.
Treating a folder of GeoTIFFs as a product. Without metadata, provenance, and a search/access layer, it is an archive, not a product. Add a STAC catalog or at least consistent metadata.
Downloading whole archives out of habit. With COG+STAC you read windows on demand; bulk download wastes storage and bandwidth.
Shapefiles for serious vector products. Field-name truncation and the 2 GB limit cause silent data loss. Use GeoPackage or GeoParquet.

Quality checks

Verify the processing level and atmospheric-correction status before trusting cross-date comparisons.
Confirm the cloud mask was applied — inspect a known cloudy scene to be sure flagged pixels are excluded.
Check the CRS and grid of ARD tiles match across dates before stacking.
Validate that a COG is actually cloud-optimised (gdalinfo shows overviews and a tiled block layout).
Record source mission, level, dates, and license/redistribution terms with every derived product.

Bathyl perspective

We design Earth data deliverables to be reusable assets, not one-off PDFs: surface-reflectance inputs, applied cloud masks, COG outputs, and a STAC or metadata layer that records exactly which scenes and parameters produced each result. The science stays traceable, and the next update extends the asset instead of rebuilding it.

Earth Data Products Explained