Key Takeaways:
- A geospatial foundation model is pretrained on huge volumes of unlabelled satellite imagery and produces reusable representations (embeddings) that can be fine-tuned cheaply for many downstream tasks
- Labels, not imagery, are the expensive constraint in Earth observation; foundation models matter because they cut the amount of labelled data you need to reach a working model
- Embeddings are compressed, numeric summaries of what is in an image; dense global embedding datasets make similarity search, stratified sampling and change-candidate detection possible at continental scale
- TerraMind (IBM and ESA) and Major TOM (ESA Phi-lab and CloudFerro) are the two most substantial open efforts with real published benchmarks and dataset scale; Prithvi (NASA and IBM) and Clay are smaller, useful open alternatives
- Benchmarks describe someone else's task, not yours; land use, licensing fit, compute budget and your own labelled validation set still decide whether a given model works for you
Every Earth observation team eventually runs into the same wall: there is more satellite imagery available than anyone could ever label. Sentinel-2 alone produces a global pass every five days. What's scarce is not the pixels, it's the annotations that turn pixels into a training set for a specific task. Geospatial foundation models are a direct response to that imbalance. This guide explains what they are, why the label-efficiency argument matters in practice, what open models are actually available today, and what to check before you commit to one.
What is a geospatial foundation model?
A foundation model, in the general machine learning sense, is a model pretrained on a very large, mostly unlabelled dataset, designed to be reused rather than trained from scratch for each new task. Geospatial foundation models apply the same idea to Earth observation: they are pretrained on huge archives of satellite imagery, often spanning multiple sensors, resolutions and time periods, using self-supervised objectives that don't require human-labelled examples.
The output of that pretraining is not a finished classifier or detector. It's a set of learned representations, usually called embeddings, that capture structure in the imagery: texture, spectral signature, spatial pattern, sometimes temporal change. A downstream task, say crop classification, flood mapping or building detection, then fine-tunes a small task-specific head on top of those representations, using a much smaller labelled dataset than would be needed to train a model from scratch.
This is the core value proposition: pretraining is expensive and happens once, on unlabelled data that is comparatively cheap to gather. Fine-tuning is cheap and happens many times, on labelled data that is comparatively expensive to produce. A well-pretrained foundation model shifts the cost curve of every downstream task that reuses it.
Why labels, not pixels, are the bottleneck
It's worth being precise about why this matters for Earth observation specifically. Satellite programs like Sentinel-2, Sentinel-1 and Landsat produce imagery on a fixed, public, repeating schedule. The imagery itself is not the constraint. Labelling it is.
A labelled dataset for a task like land cover classification, flood extent mapping or deforestation detection requires someone, often a domain expert, to annotate imagery against ground truth: field surveys, existing maps, manual photo-interpretation, or cross-referencing with other data sources. That process is slow, requires expertise, and doesn't scale the way imagery collection does. For most specific EO tasks, especially ones that are novel, regional or don't align with an existing benchmark dataset, the labelled set available to train on is small, sometimes a few hundred or a few thousand examples.
This is the label-efficiency argument for foundation models: a model that has already learned generally useful representations from unlabelled imagery needs far fewer labelled examples to reach a usable accuracy on a new task, compared with training a model from a random initialization. In practice this can mean the difference between a task being feasible with the labelled data you can realistically collect, and a task requiring a labelling effort you don't have the budget or time for.
What embeddings actually are, in plain language
An embedding is a fixed-length list of numbers that summarizes an image, or a patch of an image, in a way a model has learned to be useful. Two images that look similar, or that share a similar land cover, structure or condition, will tend to produce embeddings that are numerically close to each other. Two images that are very different will produce embeddings that are far apart.
That's the whole idea. An embedding doesn't tell you in words what's in the image. It's not a classification. It's a coordinate in a high-dimensional space that a model has organized so that "similar" content ends up in similar places. You can then do useful things with that coordinate: search for the nearest neighbours to a reference image, cluster a region into groups of similar-looking areas, or measure how far an image's embedding has moved over time as a signal of change.
What makes this powerful at scale is when embeddings are computed densely, meaning every tile or patch across a large area, and globally, meaning consistently across the whole area rather than just a handful of sample sites. A dense global embedding dataset turns Earth observation imagery into something you can query directly rather than something you have to re-inspect visually or re-run a model against every time. Three practical uses follow directly from that:
- Similarity search: given one location or image you're interested in, find every other location in a dataset whose embedding is close to it, without predefining what "similar" means in advance
- Stratified sampling: when you need to select a representative or diverse set of sites for field validation or further analysis, cluster embeddings first so your sample actually spans the variation present in the data, rather than sampling by chance
- Change candidates: flag locations where the embedding has shifted significantly between two time periods as places worth a closer look, before running a heavier, task-specific change-detection model on the full set
TerraMind: IBM and ESA's any-to-any EO model
TerraMind is an open source geospatial foundation model built by IBM and ESA, available on Hugging Face. It's designed as an any-to-any generative multimodal model for Earth observation, meaning it can take one or more EO data modalities as input and generate others, rather than being limited to a single input-output pairing.
TerraMind was pretrained on TerraMesh, a dataset of roughly 9 million spatiotemporally aligned multimodal samples, representing about 500 billion tokens. That scale and the multimodal alignment across sensors is what allows the any-to-any design to work: the model has seen enough paired examples across modalities to learn how they relate to each other, not just what each one looks like in isolation.
ESA evaluated TerraMind on PANGAEA, a community benchmark for Earth observation foundation models, where it outperformed 12 popular EO foundation models by 8 percent or more, while using roughly a tenth of the compute that would be needed to run standard models separately per modality. TerraMind is part of the FAST-EO initiative, a collaboration between DLR, Forschungszentrum Jülich, IBM Research Europe and KP Labs.
Major TOM: the largest open Sentinel embedding effort
Major TOM is a project from ESA's Phi-lab, run with CloudFerro, and it approaches the problem from the dataset side rather than the model side. Major TOM published what its authors describe as the largest ML-ready Sentinel-2 dataset available: the Core release covers over half of Earth's surface, roughly 50 terabytes and 2.5 trillion pixels.
The more directly relevant release for the embeddings use case is Major TOM's embeddings dataset, which processed over 8 million Sentinel-1 and Sentinel-2 images, about 62 terabytes of source imagery, into more than 170 million embeddings. This is described as the first open dense global embedding dataset built from Copernicus data, which is exactly the kind of resource that makes similarity search and stratified sampling at continental scale practical without every team needing to run its own embedding model over the same imagery. The embedding models used in that release include SigLIP, DINOv2 and SSL4EO. Major TOM's data is available on both Hugging Face and CREODIAS.
Prithvi and Clay: two more open options
Two other open efforts are worth knowing about, even briefly. Prithvi is a family of open geospatial foundation models developed by NASA and IBM, released for general Earth observation tasks. Clay is an open geospatial foundation model built as a nonprofit project, aimed at giving the wider EO community a freely usable pretrained model rather than a commercial product. Neither has the specific benchmark or dataset-scale figures published above for TerraMind and Major TOM, but both are legitimate options worth including in an evaluation, particularly if licensing terms or a specific data modality make them a better fit for a given project.
Where these models fall short
None of this is a case for treating foundation models as a solved problem. A few limitations are worth being direct about.
Embeddings tend to capture land cover better than land use. A model trained on spectral and spatial patterns can distinguish forest from bare soil from built-up area reasonably well, because those categories correlate strongly with what a sensor actually measures. Distinguishing a warehouse from a retail unit, or an actively farmed field from a fallow one, often depends on information the imagery doesn't directly encode, and foundation model embeddings don't magically close that gap.
Benchmark results describe someone else's task, evaluated on someone else's data, under someone else's definition of what counts as a correct answer. A model that outperforms others on PANGAEA, or on any other published benchmark, has demonstrated that it generalizes well to the specific tasks in that benchmark. It has not demonstrated that it will perform equally well on your task, in your region, against your definition of the classes you care about.
Fine-tuning and validation on your own labelled data are still required. A foundation model reduces how much labelled data you need; it doesn't remove the need for it. Any deployment decision should rest on a validation set you control and understand, not on a benchmark leaderboard position.
Model selection should be evidenced, not assumed. The only reliable way to choose between TerraMind, Major TOM's embeddings, Prithvi, Clay or any other option is to benchmark the realistic candidates against your own reference data, for your own task, before committing engineering time to a full integration.
How to choose
A short, practical checklist for evaluating a geospatial foundation model against a real project:
- Task fit: does the model's pretraining data and design match your sensor, resolution and region, or would it need to generalize well outside what it has seen
- Licence: is the model and its weights genuinely usable for your purpose, including any commercial deployment, without licensing friction
- Compute: what does inference cost at the scale you need, and does that fit your infrastructure and budget, particularly for dense, wall-to-wall coverage rather than a handful of sample tiles
- Data modality: does the model natively support the sensor types you have (optical, SAR, multitemporal stacks) or would you need to adapt your data to fit its expected input
Where Mapular fits
Mapular builds AI systems on top of geospatial data, and we run Model Context Protocol servers in production as part of that work. Our position on foundation models is a practical one: we integrate them rather than train them, choosing the model that fits a client's task, licence and infrastructure rather than defaulting to whichever one is newest. If you're weighing up whether a foundation model belongs in your pipeline, or which one to benchmark first, get in touch.
