What is Earth Observation Data? Types, Sources

Earth observation data is the imagery and measurements of the Earth's surface, oceans, and atmosphere collected by satellites, aircraft, and drones. It includes optical and radar imagery, elevation, land cover, sea surface temperature, and atmospheric gases, delivered as dated rasters: grids of pixels tied to map coordinates. Open programs such as Copernicus, NASA, and Landsat publish theirs free. The claim this article tests: most questions asked of Earth observation data end in a table of values per boundary, so the polygon is the useful unit of analysis. The walkthrough joins two products to the 78 census tracts of Boulder County, Colorado.

Key takeaways

• Earth observation data is the product of remote sensing: measurements of the planet, made from a distance, as dated rasters tied to map coordinates.
• The main types are optical, radar, thermal, atmospheric, and elevation data, plus derived products such as land cover maps and canopy height.
• Each dataset has four resolutions (spatial, spectral, temporal, radiometric) and a processing level from 0 (raw) to 4 (model output).
• Public data from NASA, the U.S. Geological Survey (USGS), and Copernicus is free. Commercial providers sell finer resolution and more frequent revisits.
• The archive is large, so analysis reads files in place in cloud storage.
• In Wherobots, SQL summarizes several products over the same boundaries in one table.

What is Earth observation data?

The Group on Earth Observations is the intergovernmental partnership that coordinates the Global Earth Observation System of Systems. It defines Earth observations as data and information about the planet's surface, oceans, and atmosphere, collected by sensors in space, in the air, or on the ground. In practice it most often means satellite and airborne data.

Remote sensing is the technique and Earth observation data is its product. Sensors are passive or active. In NASA's guide to passive and active instruments, passive sensors record energy reflected or emitted by the surface, such as sunlight or heat. Active sensors, such as radar and lidar, send out their own pulse and measure what returns.

The record starts with weather. NASA launched TIROS-1, the first successful weather satellite, on April 1, 1960, and Landsat began imaging land in 1972. Satellites image the same ground on a fixed orbit and schedule. The record therefore forms a time series over every place, including places no one has studied yet.

Types of Earth observation data

Type	What it measures	Example sources
Optical (multispectral, hyperspectral)	Reflected sunlight in visible and infrared bands	Sentinel-2, Landsat, PlanetScope
Radar (SAR)	Microwave backscatter, day or night, through cloud	Sentinel-1, NISAR, ICEYE
Thermal	Emitted heat, as land or sea surface temperature	Landsat Thermal Infrared Sensor (TIRS), MODIS, VIIRS
Atmospheric	Gases, aerosols, and clouds	Sentinel-5P TROPOMI, GOES
Elevation	Height of terrain and surface objects	Lidar, TanDEM-X, Copernicus DEM
Derived products	Land cover, vegetation indices, canopy height, soil moisture	ESA WorldCover, NDVI, Meta canopy height

Derived products are made from sensor data in one or more processing steps. A digital elevation model (DEM) such as the Copernicus DEM comes from radar interferometry, which computes height from radar images taken from two positions. A land cover map comes from classified imagery. Often they are the layer the analyst queries.

How Earth observation data works

Spatial, spectral, temporal, and radiometric resolution

NASA's guide to resolution describes every dataset by four kinds of resolution:

Resolution	What it measures
Spatial	The ground size of a pixel
Spectral	The number and width of the bands
Temporal	How often the sensor revisits the same place
Radiometric	How finely the sensor separates small differences in energy

Mission designers trade one resolution against the others. A 30 cm commercial image covers a small area. A weather imager in geostationary orbit, fixed above one point on the equator, covers a whole hemisphere at kilometer scale every few minutes.

Processing levels

Earth observation data is published by processing level. The levels below follow NASA's data processing levels.

Level	What it contains	Ready for
0	Raw instrument data at full resolution	Reprocessing only
1	Time-referenced, calibrated, georeferenced radiance or amplitude	Visualization, custom processing
2	Geophysical variables at the pixel, such as surface reflectance or backscatter, with quality masks	Analysis
3	Variables mapped onto uniform grids in space and time, such as composites and mosaics	Time series, mapping
4	Model output or results from analyses of lower levels, such as biomass or soil moisture	Decision products

Analysis Ready Data removes most of that preparation. The Committee on Earth Observation Satellites (CEOS) defines CEOS Analysis Ready Data as satellite data processed to a minimum set of requirements. It is organized so it can be analyzed at once and combined through time and with other datasets. Landsat Collection 2 and Sentinel-2 Collection-1 are examples.

Formats and discovery

Most Earth observation data is raster.

Format	What it is	What it holds
Cloud Optimized GeoTIFF	An image file laid out so a program can read part of it over the network	Imagery, the common format
NetCDF and Zarr	Arrays with more than two dimensions, such as time	Atmospheric and ocean data
Point cloud	A set of 3D points	Lidar
GeoParquet	A table file format with a geometry column	Derived vector products such as detected buildings

Users find scenes through STAC, the SpatioTemporal Asset Catalog, which indexes each scene by footprint, date, and file URL. The Open Geospatial Consortium (OGC) published STAC 1.1 as an OGC Community Standard in October 2025. Most open archives on AWS, Microsoft Planetary Computer, and the Copernicus Data Space Ecosystem offer a STAC search API.

According to the Copernicus Data Space Ecosystem's 2024 annual report, Copernicus generates up to 40 TB of data a day, and the ecosystem holds almost 80 PB online. At that volume, analysis reads the files where they are stored, in cloud object storage. The result is a table: a value per field, parcel, or boundary, per date.

Earth observation data sources

Public programs publish their data free:

Program	What it publishes	Access
NASA	NASA Earthdata serves NASA's Earth science archive	Free and open since the start of the Earth Observing System program in 1990; downloads need only a free Earthdata Login
Copernicus	The European Union's program runs the Sentinel missions	EU law gives users free, full, and open access to Copernicus Sentinel data, including reproduction, modification, and redistribution
USGS	Operates Landsat and keeps its archive, back to 1972, at its Earth Resources Observation and Science (EROS) Center	Free
NOAA	Runs the geostationary GOES and polar weather satellites	Free
NISAR	NASA and Indian Space Research Organisation (ISRO) radar satellite, launched on July 30, 2025; the first mission to collect radar in both L-band and S-band, two radar wavelength ranges	All science data free

Commercial providers sell finer resolution or more frequent revisits. Planet markets daily coverage of the Earth's land from PlanetScope. Vantor (formerly Maxar) and Airbus sell 30 cm class optical imagery. ICEYE runs a commercial fleet of synthetic aperture radar (SAR) satellites. Licensed imagery costs money. The exception is disasters. The Vantor Open Data Program releases before and after imagery of major events under a Creative Commons Attribution-NonCommercial license (CC BY-NC 4.0).

Earth observation data examples

• Weather forecasting. NOAA, the National Oceanic and Atmospheric Administration, runs the Geostationary Operational Environmental Satellites (GOES). The Advanced Baseline Imager on GOES captures a full disk image every 10 minutes and the continental United States every 5 minutes. A full disk image shows the whole face of the Earth visible from the satellite.
• Wildfire detection. NASA publishes active fire detections worldwide within 3 hours of a satellite pass. They come from two imagers: the Moderate Resolution Imaging Spectroradiometer (MODIS) and the Visible Infrared Imaging Radiometer Suite (VIIRS). The service is FIRMS, the Fire Information for Resource Management System.
• Flood mapping. The Copernicus Emergency Management Service produces flood and damage maps from optical and radar imagery within hours to days of a disaster.
• Methane leaks. Lauvaux and colleagues' Global assessment of oil and gas methane ultra-emitters (Science, 2022) found ultra-emitters, oil and gas sites with extreme methane releases. The sites showed up in images from TROPOMI, the TROPOspheric Monitoring Instrument on Sentinel-5P. The authors estimate that these sites emit 8 to 12% of global oil and gas methane emissions.
• Land cover. ESA WorldCover, from the European Space Agency (ESA), is a 10 m map of the world in 11 classes for 2021, classified from Sentinel-1 and Sentinel-2.
• Forests and tree height. Landsat time series map annual forest loss, as the Landsat article describes. Tolan and colleagues' 1 m canopy height maps from RGB imagery (Remote Sensing of Environment, 2024) estimated tree height at 1 m from commercial imagery. Their model was trained on aerial lidar.
• Insurance and supply chains. Insurers measure exposure before an event and damage after it across a portfolio. Supply chain teams watch ports and mines for activity, as in the Wherobots Strait of Hormuz vessel detection study.

Earth observation data in Wherobots

WherobotsDB reads Earth observation data where it is stored: in public archives, or in a customer's own S3 bucket or Iceberg catalog. It joins that data to vector data in the same SQL query: raster and vector in one engine, where most stacks pick one. RS_FromPath opens a Cloud Optimized GeoTIFF as an out-db raster, a reference to the remote file. Pixels are read only when a function uses them. The STAC reader does the same for whole catalogs. It returns one row per scene, with each band registered as an out-db raster.

The running example joins two Earth observation products to the 78 census tracts of Boulder County, Colorado. The first is the Copernicus DEM GLO-30, a 30 m surface elevation model from TanDEM-X radar. The second is ESA WorldCover 2021. The county runs from the plains east of the city of Boulder to the Continental Divide, so the two products describe contrasting places within one county. Both rasters are read in place from their public buckets on AWS.

Source	Format and location	Size	What the queries read
US Census TIGER census tracts	Vector table with a geometry column, wherobots_open_data.us_census.tiger_tract	78 tracts in Boulder County	Tract ID (GEOID) and polygon for state 08, county 013
Copernicus DEM GLO-30	Cloud Optimized GeoTIFF, public copernicus-dem-30m bucket on AWS	2 tiles (N39 W106, N40 W106); 2.6 million 30 m pixels inside the tracts	Band 1, surface elevation in meters
ESA WorldCover 2021 (v200)	Cloud Optimized GeoTIFF, public esa-worldcover bucket on AWS	1 file (N39W108) of 36,000 by 36,000 10 m pixels; 29.2 million pixels inside the tracts	Band 1, land cover class: 10 (tree cover) and 50 (built-up), from the 1024 by 1024 pixel tiles that cross the county's bounding box

Each summary is one SQL query that joins raster pixels to tract polygons.

Elevation by census tract

This query reads two Copernicus DEM GLO-30 tiles from the public bucket and averages surface elevation over each tract with RS_ZonalStatsAll:

WITH t AS (
  SELECT GEOID, geometry
  FROM wherobots_open_data.us_census.tiger_tract
  WHERE STATEFP = '08' AND COUNTYFP = '013'            -- Boulder County, Colorado
),
dem AS (                                               -- Copernicus DEM GLO-30, read in place on AWS
  SELECT RS_FromPath('s3://copernicus-dem-30m/Copernicus_DSM_COG_10_N40_00_W106_00_DEM/Copernicus_DSM_COG_10_N40_00_W106_00_DEM.tif') AS rast
  UNION ALL
  SELECT RS_FromPath('s3://copernicus-dem-30m/Copernicus_DSM_COG_10_N39_00_W106_00_DEM/Copernicus_DSM_COG_10_N39_00_W106_00_DEM.tif')
),
z AS (
  SELECT t.GEOID, RS_ZonalStatsAll(dem.rast, t.geometry, 1, false, true) AS s
  FROM t JOIN dem ON RS_Intersects(dem.rast, t.geometry)
)
SELECT GEOID,
       SUM(s.count)              AS pixels,
       SUM(s.sum) / SUM(s.count) AS mean_elev_m,
       MAX(s.max)                AS max_elev_m
FROM z
WHERE s.count > 0
GROUP BY GEOID

The query returned all 78 tracts and summarized 2.6 million 30 m pixels. Tract means run from 1,511 m on the plains to 3,079 m in the high mountains. The highest pixel, 4,341 m, lies in the county's largest tract, on its western edge along the Continental Divide.

Land cover by census tract

The land cover query needs more care. A single ESA WorldCover file covers 3 by 3 degrees at 10 m, or 36,000 by 36,000 pixels. RS_TileExplode splits it into out-db tiles of 1024 by 1024 pixels. Each tile is a reference to part of the same remote file. A filter on the county's bounding box keeps only the tiles the join needs. RS_MapAlgebra turns each tile into a mask for one class: 1 where a pixel is in the class, 0 elsewhere. The mean of the mask over a tract is that class's share of the tract:

WITH t AS (
  SELECT GEOID, geometry
  FROM wherobots_open_data.us_census.tiger_tract
  WHERE STATEFP = '08' AND COUNTYFP = '013'
),
wc AS (
  SELECT RS_TileExplode(RS_FromPath('s3://esa-worldcover/v200/2021/map/ESA_WorldCover_10m_2021_v200_N39W108_Map.tif'), 1024, 1024) AS (x, y, rast)
),
w AS (
  SELECT rast FROM wc
  WHERE RS_Intersects(rast, ST_GeomFromText('POLYGON((-105.70 39.91, -105.05 39.91, -105.05 40.27, -105.70 40.27, -105.70 39.91))'))
),
z AS (
  SELECT t.GEOID,
         RS_ZonalStatsAll(RS_MapAlgebra(w.rast, 'D', 'out = rast[0] == 10 ? 1 : 0;'), t.geometry, 1, false, false) AS tree,
         RS_ZonalStatsAll(RS_MapAlgebra(w.rast, 'D', 'out = rast[0] == 50 ? 1 : 0;'), t.geometry, 1, false, false) AS built
  FROM t JOIN w ON RS_Intersects(w.rast, t.geometry)
)
SELECT GEOID,
       SUM(tree.count)                   AS pixels,
       SUM(tree.sum) / SUM(tree.count)   AS tree_share,
       SUM(built.sum) / SUM(built.count) AS built_share
FROM z
WHERE tree.count > 0
GROUP BY GEOID

It returned all 78 tracts from 29.2 million pixels in about two and a half minutes. Class 10 is tree cover and class 50 is built-up in the WorldCover legend. Across the county, 50.9% of the pixels are tree cover and 5.4% are built-up.

What the join shows

A join on GEOID, the tract ID, puts both results in one row per tract. Most Earth observation workflows end in a table like this:

	Tracts	Mean elevation	Tree cover share
Tract mean below 1,700 m (plains and cities)	66	1,511 to 1,697 m	median 22%
Tract mean 2,000 m or more (mountains)	5	2,025 to 3,079 m	63 to 81%
Whole county	78	1,511 to 3,079 m	50.9% of pixels

Each finding below needs both products in one table. Elevation and tree cover are correlated (correlation coefficient r = 0.64). The five mountain tracts that average 2,000 m or more hold 58% of the county's land. The city tracts break the pattern. Thirty-three tracts are 40% or more built-up, and all lie below 1,700 m. Their median tree cover share is 30%, against 12% for the other 33 tracts below 1,700 m.

The county figure counts every pixel equally (50.9% tree cover), and it differs from the tract median (22% below 1,700 m). Census tracts are drawn to hold similar numbers of people. So the many small tracts are in the low, populated east, and the few large ones are in the forested west. Which number is right depends on whether the question is about land or about people. This is the modifiable areal unit problem: a summary changes with the boundaries chosen.

The Copernicus DEM is a surface model, so its heights include trees and buildings. WorldCover describes 2021, and the tract boundaries come from the current release of TIGER (Topologically Integrated Geographic Encoding and Referencing), the Census Bureau's map files.

Beyond one county

The same pattern scales to every county in a state, or swaps tracts for building footprints or parcels. RS_MapAlgebra also computes indices such as NDVI (normalized difference vegetation index) from imagery bands. Havasu, the Apache Iceberg table format extended with raster and geometry types, stores the results. RasterFlow (Public Preview) builds mosaics from imagery, runs computer vision inference on them, and writes the results as vectorized outputs on the same platform. The Wherobots Data Hub offers ready tables, including the Copernicus DEM, Sentinel-2 Level-2A scenes, and USDA NAIP imagery. Over the Model Context Protocol (MCP), the Wherobots MCP Server gives Claude Code and other AI coding tools access to the same catalog and functions. WherobotsDB is built by the original creators of Apache Sedona and is 100% code compatible with it across all spatial functions.

Earth observation data research

Four research threads made Earth observation data something geospatial analysis can query: analysis ready data, data cubes, distributed query engines, and learned representations.

From scenes to analysis ready data

For most of its history Earth observation data was delivered as scenes. Each user corrected them, masked bad pixels, and reprojected them to a common map projection before any analysis. Dwyer, Roy, and colleagues' Analysis Ready Data: Enabling Analysis of the Landsat Archive (Remote Sensing, 2018) set out the alternative. Process the archive once, to surface reflectance (the share of sunlight the ground reflects) on a fixed grid, with quality flags per pixel. Every time series analysis then starts from a consistent stack. The CEOS framework turned that idea into a specification.

That consistency requires reprocessing. ESA reprocessed the Sentinel-2 archive from 2015 to December 2023 to processing baseline 05.00 for Collection-1, a volume of 26 PiB. Enache and colleagues describe the work in Copernicus Sentinel-2 Collection-1 (IGARSS, 2023). A processing baseline is a fixed version of the processing algorithms. Each reprocessing changes the numbers in every derived product built on it. So provenance, the record of which baseline and collection produced a value, belongs in the table next to the value.

Data cubes

The data cube is the main research approach to computing on a whole archive. Lewis and colleagues' The Australian Geoscience Data Cube: Foundations and lessons learned (Remote Sensing of Environment, 2017) organized the Landsat archive over Australia as a stack of tiles. The tiles are indexed by space and time. That design became the Open Data Cube. Mahecha and colleagues' Earth system data cubes unravel global multivariate dynamics (Earth System Dynamics, 2020) generalized it. Their design treats space, time, and variables as axes of one array and applies functions along any of them. Appel and Pebesma's On-demand processing of data cubes from satellite image collections with the gdalcubes library (Data, 2019) builds cubes on demand from image collections. Because of that, each cube exists only for the duration of one analysis.

Gomes, Queiroz, and Ferreira's An overview of platforms for big Earth observation data management and analysis (Remote Sensing, 2020) compares the systems built on these ideas. They range from Google Earth Engine to the Open Data Cube and openEO. Gorelick and colleagues' Google Earth Engine: Planetary-scale geospatial analysis for everyone (2017) made server-side computation over the full public archive the default for many researchers.

Big Earth data and distributed computing

Ma and colleagues' Remote sensing big data computing: Challenges and opportunities (Future Generation Computer Systems, 2015) framed remote sensing data as a big data problem for computing systems. Sudmanns and colleagues' Big Earth data: disruptive changes in Earth observation data management and analysis? (International Journal of Digital Earth, 2020) examined how users shift, as volume grows, from downloading scenes to working on data where it is stored.

A data cube stores everything as arrays. Most questions asked of Earth observation data end in a vector join: pixels summarized per parcel, building, tract, or watershed. Jia Yu, Jinxuan Wu, and Mohamed Sarwat's GeoSpark: A cluster computing framework for processing large-scale spatial data (ACM SIGSPATIAL, 2015) introduced spatial partitioning and indexing for vector joins. The joins run across a cluster of machines in Apache Spark. Yu, Zhang, and Sarwat's Spatial data management in Apache Spark: the GeoSpark perspective and beyond (GeoInformatica, 2019) described the full system that became Apache Sedona. Sedona later added raster types and functions. A join of pixels to polygons now runs in the same engine and query plan as a vector join, the pattern the Boulder County queries use. The Wherobots post on raster spatial joins at scale compares that approach with Google Earth Engine and BigQuery.

Derived products and learned representations

The Copernicus DEM descends from TanDEM-X. Rizzoli and colleagues document the TanDEM-X global elevation model in Generation and performance assessment of the global TanDEM-X digital elevation model (ISPRS Journal of Photogrammetry and Remote Sensing, 2017). They report a global vertical error of 3.49 m as linear error at the 90th percentile (LE90). The reference heights came from the Ice, Cloud, and land Elevation Satellite (ICESat), a lidar satellite. The Global Ecosystem Dynamics Investigation (GEDI) measures forest height with a space lidar in 25 m footprints. Dubayah and colleagues describe it in The Global Ecosystem Dynamics Investigation (Science of Remote Sensing, 2020). These samples are used to calibrate and check canopy height maps that cover every pixel.

Learned representations are the newest derived product. Zhu and colleagues' Deep learning in remote sensing: a comprehensive review and list of resources (IEEE Geoscience and Remote Sensing Magazine, 2017) reviewed the shift to neural networks. Brown and colleagues' AlphaEarth Foundations (arXiv, 2025) describes a model that compresses optical, radar, and climate observations into a 64-dimensional embedding. The model produces one embedding for every 10 m land pixel each year from 2017 to 2024. The embedding, a list of 64 numbers per pixel that summarizes those observations, is a raster like any other. It joins to boundaries the same way, as the Wherobots post on AlphaEarth embeddings and zonal statistics shows.

Open problems

• Uncertainty through the levels. A Level 4 product carries the errors of every step below it, and few producers publish per-pixel uncertainty that can be carried through to a polygon summary.
• Mismatched grids. A 30 m DEM, a 10 m land cover map, and a 1 m canopy map share no pixel grid. Summarizing each layer to the same polygon avoids resampling, the conversion of a raster to another pixel grid. The cost is the modifiable areal unit problem: results change with the boundaries chosen.
• Time alignment. The DEM, the land cover map, and an optical scene in one query describe different years. Most derived products are annual or static, while the questions asked of them are about this week.

Conclusions

The Boulder County queries show what Earth observation data is in practice: dated rasters in cloud storage, read in place and summarized to boundaries as a table.

1. Earth observation data is published by level, so query the derived product and know its level. The Boulder analyses used Level 3 and 4 products, the Copernicus DEM and WorldCover. Use Level 2 imagery when no product has the variable or date.
2. Earth observation archives hold petabytes, so read the data in place. Copernicus alone adds up to 40 TB a day to an 80 PB archive. The Boulder queries summarized 2.6 million and 29.2 million pixels from public Cloud Optimized GeoTIFFs on AWS with no copy step.
3. A summary of Earth observation data depends on the boundary, so name the boundary. Tree cover is 50.9% of Boulder County's pixels and 22% for the median tract below 1,700 m. Land questions take the figure that counts every pixel equally. A question about people needs tract figures weighted by population, which this query did not compute.
4. Each Earth observation value depends on its product, date, and processing version, so carry them with it. The DEM is a surface model that includes trees and buildings. WorldCover describes 2021. Each reprocessing changes the numbers downstream.
5. Earth observation analysis usually ends in a join of products per boundary, so build it as one. Elevation and tree cover correlate at r = 0.64 across 78 tracts, measured in one table.
6. Open Earth observation data covers most regional questions, with one hedge. Public 10 m to 30 m imagery answers regional questions. Outside NAIP's US coverage, 30 cm detail or daily imagery finer than 250 m needs licensed commercial imagery, with Vantor disaster releases as a free exception.

Related terms

• Sentinel-2: the Copernicus optical mission with 10 m bands
• Landsat: the longest-running land imaging archive, since 1972
• SAR data: the all-weather radar branch of Earth observation
• Hyperspectral imagery: hundreds of narrow bands
• Digital elevation model: the elevation product used here
• Satellite imagery analysis: methods that extract measurements from scenes
• Raster vs vector data: why Earth observation analysis needs both
• Geospatial data: vector and raster data, including Earth observation data
• Geospatial intelligence: the analysis that answers questions about activity from Earth observation data

Read more from Wherobots

• Raster processing at scale: the out-of-database architecture behind WherobotsDB
• Raster spatial joins at scale: Google Earth Engine and BigQuery vs Apache Sedona and Wherobots
• Measuring the Strait of Hormuz shutdown with Sentinel-2, WherobotsDB and Overture Maps
• RasterFlow is now available in Public Preview
• ML for Earth observation
• Introduction to the Data Hub

Query Earth observation data in place with WherobotsDB at cloud.wherobots.com.