OlmoEarth v1.3 Embeddings

This dataset holds annual embeddings of the Earth's land surface at 10 m resolution, produced by OlmoEarth-v1.3-Base from Sentinel-1, Sentinel-2, and Landsat 8/9 imagery. Each pixel has one 128-dimensional vector per calendar year, summarizing that year of satellite observations. The first 64 dimensions can be used as a standalone embedding. The vectors are meant to be used as input features: fit a classifier or regressor on labeled points, then apply it across a region without needing the source imagery or running the model yourself.

Note: As of the initial release on October 22, 2026, 2024 and 2025 are global and 2023 is near-global, with the remaining regions being filled now. 2017 through 2022 cover selected countries and are being backfilled over the same extent in the coming weeks.

What's included

Related:

• Model weights: allenai/OlmoEarth-v1_3-Base
• Paper: OlmoEarth v1.3 Embeddings
• Interactive explorer: olmoearth.allenai.org/embeddings

Accessing the data

The dataset is hosted on Source Cooperative and read through its S3-compatible data proxy at https://data.source.coop. Access is public and anonymous: no account, API key, or request signing.

Use libraries that read Zarr with ranged requests rather than downloading whole files. The Cloud-Native Geospatial Forum's Zarr guide explains how that works. The examples below need:

Embeddings layout

embeddings.zarr has one group per UTM zone, utm01 through utm60. Each zone holds a single embeddings array with four axes:

Coverage

The coverage area is the union of land, full-resolution shorelines (which keep barrier islands and atolls), and water that all three modalities observe consistently, taken as at least 11 months in at least 7 of the years 2017 through 2025. That last part takes in most of the coastal zone. The grid follows the UTM system, which spans 80°S to 84°N. Within it, the coverage area runs from 59.5°S to 83.6°N and does not include Antarctica. Every 2048 x 2048 pixel window that touches the coverage area is computed in full, water included.

Magenta is the extent the embeddings cover once every year is complete. assets/coverage.tif is the same extent as a 0.05° mask, with 1 where embeddings are expected. Both are drawn in blocks of 8192 x 8192 pixels, so near coasts they include some water that has no embeddings.

Reading the embeddings

Read one location

q is an int8 array of shape (128,). The same code works in both hemispheres.

Dequantize

The values are quantized to int8 with a signed square-root scheme and must be converted back to float before use:

Nodata becomes NaN, so it cannot leak into a mean or a distance.

Read an area

Use 64 dimensions

The model was trained with nested (Matryoshka) embeddings, so the first 64 dimensions form a complete embedding on their own. They perform well on most tasks. Read all 128 for tasks that need the extra detail.

Bands 0:64 are stored in their own chunks, so reading them downloads half the data:

Provenance

provenance/ records which satellite scenes went into every embedding. It holds three GeoParquet tables, each with one file per year:

Each scene links to its item in a public STAC catalog: Microsoft Planetary Computer for Sentinel-1 RTC and Sentinel-2 L2A, and USGS for Landsat Collection 2 Level-1. See provenance/README.md for the columns and example queries.

Caveats

• Nodata does not mean no land. -128 means no embedding was computed for that pixel: it is outside the coverage area, or none of that year's Sentinel-2 30-day mosaics had imagery there.
• A narrow strip at the antimeridian has no embeddings. In zones 1 and 60, the one window crossing 180 degrees is skipped every year: its WGS84 bounds span nearly the globe, so the imagery search for it is unreliable.
• Dequantize before any arithmetic. The quantization is non-linear, so distances on the raw int8 values are not proportional to distances between embeddings.
• The vectors are not L2-normalized. Their magnitude carries signal: the per-pixel norm over 128 dimensions runs about 3.0 to 3.8, median 3.4. If computing cosine similarity as a dot product, L2-normalize the vectors first.
• Do not compare 64-dimensional and 128-dimensional vectors. Pick one width for an analysis.
• Each zone has its own projection. Zones are separate UTM CRSs, so an area that crosses a zone boundary needs one read per zone, reprojected onto a common grid.
• Southern zones use the northern CRS. Every zone is stored in EPSG:326NN, so southern locations have a negative y instead of the usual 10,000,000 m false northing. PROJ handles this correctly, but tools that assume non-negative northings may complain.
• Turn off chunk coalescing for small reads on zarr 3.3 and later. It merges nearby reads into one request and fetches the gaps between them. The examples above disable it with zarr.config.set({"array.sharding_coalesce_max_gap_bytes": 0}).

Metadata

Every group lists the conventions it follows in zarr_conventions:

• Embeddings Zarr Convention (geoemb:), for model provenance
• spatial and proj, for the grid and CRS
• license, for the license URL

Two additions go beyond those conventions:

• geoemb:matryoshka_dims lists the prefix widths the encoder was trained to support, [128, 64].
• geoemb:quantization uses a signed_power method that the convention does not define. Its power, formula, valid_range, and nodata fields give everything needed to dequantize.

Citation

If you use this dataset, please cite the paper:

License

Released under the OlmoEarth Artifact License.

Contact

olmoearth@allenai.org