Understanding Scale in Earth Engine

The four types of resolution

Resolution defines the level of detail your sensor can capture. Remote sensing scientists recognize four distinct types of resolution, each describing a different dimension of data quality:

1. Spatial Resolution

Spatial resolution refers to the size of each pixel on the ground, also called the ground sampling distance. A 30-meter resolution means each pixel represents a 30 × 30 meter area on Earth's surface.

• High spatial resolution (1–10 m): Planet, Sentinel-2 (some bands), commercial satellites. Best for urban mapping, infrastructure, and fine-scale analysis.
• Medium spatial resolution (10–100 m): Landsat (30 m), Sentinel-2. Workhorse for regional studies, land cover classification.
• Coarse spatial resolution (100–1000+ m): MODIS (250–1000 m), GOES. Best for global monitoring, climate studies, daily observations.

Key insight: Smaller pixels (finer resolution) capture more detail but dramatically increase data volume. A large pixel might mix different land cover types into a single averaged value—a phenomenon called the mixed pixel problem.

2. Temporal Resolution

Temporal resolution is the revisit period—how frequently a satellite captures imagery of the same location.

• High temporal resolution (daily or sub-daily): Planet, geostationary satellites (GOES captures every 5–15 minutes!). Essential for monitoring rapid changes like floods, fires, or weather.
• Medium temporal resolution (5–16 days): Sentinel-2 (~5 days), Landsat (~16 days). Good balance for agriculture, phenology, change detection.
• Low temporal resolution (monthly or less): Some specialized missions. Useful when change is slow.

Trade-off: Higher temporal resolution often means coarser spatial resolution. Geostationary satellites offer near-continuous observation but at kilometer-scale pixels.

3. Spectral Resolution

Spectral resolution describes the number and width of wavelength bands the sensor records. It determines what materials and conditions you can distinguish.

• Panchromatic (1 broad band): High spatial detail but no color distinction.
• Multispectral (4–12 bands): Landsat (11 bands), Sentinel-2 (13 bands). Enables vegetation indices, water detection, basic material identification.
• Hyperspectral (100–400+ narrow bands): AVIRIS, PRISMA, EnMAP. Can identify specific minerals, vegetation species, water quality parameters.

Why it matters: More spectral bands let you distinguish materials that look identical in RGB. For example, NIR bands reveal vegetation health invisible to the human eye; SWIR bands detect moisture content and mineral composition.

4. Radiometric Resolution

Radiometric resolution is the sensor's ability to distinguish subtle differences in energy levels—determined by the bit depth of the recorded values.

• 8-bit (256 levels): 0–255. Older sensors, consumer cameras. Limited dynamic range.
• 12-bit (4,096 levels): Landsat 8, Sentinel-2. Much better discrimination of subtle brightness variations.
• 16-bit (65,536 levels): Some scientific instruments. Excellent for detecting small changes.

Practical impact: Higher radiometric resolution captures subtle reflectance differences—essential for detecting small changes in water quality, vegetation stress, or distinguishing shadows from dark objects.

How Earth Engine handles scale: Image pyramids

Understanding why scale matters requires knowing how Earth Engine stores and processes data internally. This is key to avoiding unexpected results.

Image pyramids explained

Earth Engine stores every image as a multi-resolution pyramid. At the base is the full-resolution (native) data. Above it are progressively coarser aggregated versions—each level has pixels that represent averages or samples of the level below.

┌───────────────────┐  ← Level 3: Very coarse (e.g., 240m)
│      1 pixel      │     Aggregated from Level 2
└───────────────────┘
        ↑
┌───┬───┬───┬───┐      ← Level 2: Coarse (e.g., 120m)  
│   │   │   │   │        Each pixel = 4 from Level 1
└───┴───┴───┴───┘
        ↑
┌─┬─┬─┬─┬─┬─┬─┬─┐      ← Level 1: Medium (e.g., 60m)
│ │ │ │ │ │ │ │ │        Each pixel = 4 from Level 0
└─┴─┴─┴─┴─┴─┴─┴─┘
        ↑
┌┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┐      ← Level 0: Native resolution (e.g., 30m)
└┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┘        Original sensor data
                        

What happens when you request data?

When you run a computation or export, Earth Engine uses the scale parameter to decide which pyramid level to pull data from:

• Request at native scale (30m for Landsat): You get actual sensor pixels from Level 0.
• Request at coarser scale (100m): Earth Engine pulls from a higher pyramid level with pre-aggregated pixels—faster, but values differ from native.
• Request at finer scale (10m on 30m data): Earth Engine upsamples the native data using interpolation—no new detail is created, just smoothed pixels.

Why the same location can have different values

Because each pyramid level represents aggregated data, the pixel value at a location can differ depending on which level is queried. For example, if you run reduceRegion at 10m, 30m, and 100m for the same point:

• At 10m: Interpolated/upsampled from the 30m native data
• At 30m: Actual native sensor value
• At 100m: Aggregated value (average of multiple native pixels)

All three may return different numbers for the same geographic location. This is expected behavior—not a bug—but it's why you must be intentional about scale.

Always set scale explicitly

According to the Earth Engine Developer Guide: "In general, it is best to always specify scale, crs, and crsTransform when performing reductions or exports."

In reducers

// Good: scale explicitly set to match Landsat native resolution
var stats = image.reduceRegion({
  reducer: ee.Reducer.mean(),
  geometry: roi,
  scale: 30,           // Always specify!
  maxPixels: 1e9       // Optional: raise limit for large regions
});
print('Mean reflectance:', stats);

In exports

// Good: export at explicit scale and projection
Export.image.toDrive({
  image: image,
  description: 'my_export',
  region: roi,
  scale: 30,           // Controls output resolution
  crs: 'EPSG:32610',   // Optional: specify coordinate system
  maxPixels: 1e13      // Raise for large exports
});

Handling "too many pixels" errors

Earth Engine limits computations to prevent runaway processing. The default limit for reduceRegion is about 10 million pixels. For context:

• A 1° × 1° area (~12,000 km²) at 30m = ~13 million pixels → exceeds default!
• Same area at 100m = ~1.2 million pixels → easily within limits
• Same area at 500m = ~48,000 pixels → very fast

// Strategy: Coarsen scale first, then optionally raise limits
var stats = image.reduceRegion({
  reducer: ee.Reducer.mean(),
  geometry: largeArea,
  scale: 100,          // ← First line of defense: coarser scale
  maxPixels: 1e9,      // ← Second: raise the limit if needed
  bestEffort: true     // ← Last resort: auto-coarsen if still too many
});

Mixing datasets with different resolutions

Real projects often combine data from multiple sensors—Landsat with Sentinel, optical with elevation, etc. These datasets have different native resolutions and projections. Here's how to handle them properly.

The problem

When you combine images with different resolutions (e.g., Sentinel-2 at 10m + Landsat at 30m), Earth Engine must resample one to match the other. By default, it uses nearest-neighbor resampling, which can produce blocky artifacts.

Resampling methods

• Nearest neighbor (default): Takes value from closest pixel. Fast, preserves exact values. Best for categorical data (land cover classes).
• Bilinear: Averages 4 nearest pixels. Smoother result. Best for continuous data (reflectance, temperature, elevation).
• Bicubic: Averages 16 nearest pixels. Smoothest but slowest. Good for elevation data.

// Example: Resampling a DEM to match Landsat before combining
var dem = ee.Image('USGS/SRTMGL1_003');  // 30m but different projection
var landsat = ee.Image('LANDSAT/LC08/C02/T1_L2/LC08_044034_20210623');

// Resample DEM using bilinear for smooth elevation
var demResampled = dem
  .resample('bilinear')
  .reproject({
    crs: landsat.projection(),
    scale: 30
  });

// Now safe to combine
var combined = landsat.addBands(demResampled.rename('elevation'));

Choosing an analysis scale when mixing

When combining Sentinel-2 (10m) with Landsat (30m):

• Analyze at 30m: Sentinel-2 gets downsampled (averaged). You lose some detail but both datasets contribute equally weighted information.
• Analyze at 10m: Landsat gets upsampled (interpolated). The 10m pixels from Landsat are just smoothed versions of 30m data—no new detail is created.

Rule of thumb: Use the coarsest native resolution of your inputs as your analysis scale, unless you have a specific reason to need finer resolution from one source.

Next steps

• Experiment with scale: Run the same reducer at 10m, 30m, 100m, and 500m. Compare runtime and results.
• Compare resampling methods: Visualize DEM data resampled with nearest, bilinear, and bicubic. Note the differences.
• Explore band resolutions: Use nominalScale() on each band of a Sentinel-2 image. Which bands are 10m? 20m? 60m?
• Practice exports: Export a classified image with explicit scale and crs for reproducible results.

📚 Further reading

• Google Earth Engine Guide: Scale — Official documentation on how Earth Engine handles scale
• Google Earth Engine Guide: Resampling and Reducing Resolution — How to control interpolation
• NASA Earthdata: Remote Sensing Basics — Authoritative introduction to the four resolutions
• Pan Geography: Types of Resolution — Clear explanations with examples