Remote Sensing
Applications

The four resolutions, as a set of trade-offs

You know the definitions. What matters now is that you cannot have all four at once, because they trade against each other through the physics of the instrument. A detector element collects a fixed amount of energy; make the ground footprint smaller and less energy arrives, so to keep the signal-to-noise ratio usable you must widen the spectral bands or lengthen the dwell time. Every satellite is one settled compromise, and choosing among them is the first professional decision in any project.

If the application needs…	You are buying it with…
Fine spatial detail — individual buildings, field boundaries	Narrower swath, so less frequent revisit; and usually cost
Frequent revisit — crop phenology, flood response	Coarse pixels, because a wide swath means a large footprint
Many narrow spectral bands — mineralogy, water quality	Coarser pixels and a lower signal-to-noise ratio
Fine radiometric sensitivity — subtle water or thermal differences	Wider bands or larger pixels

State the requirement before you choose the sensor. "Map crop types across Trans Nzoia" needs enough revisit to catch the phenological sequence and enough spatial detail to resolve fields — Sentinel-2 at 10 m every five days. "Map informal settlement structures" needs metres, not tens of metres, and revisit hardly matters — commercial very-high-resolution imagery. "Track a flood over three days under cloud" needs radar, and nothing else will do.

Spectral signatures — the foundation of everything that follows

Read that figure as a set of practical rules. Vegetation is separated from soil in B8 far more strongly than in any visible band. Water is separated from everything in B8 and B11. Two vegetation types that look identical in the visible may differ in the SWIR because of moisture content. When a classification confuses two classes, the first question is which band would separate them? — and the answer usually comes from this figure.

It also explains the standard false-colour composite. Put B8 in the red channel, B4 in green, B3 in blue, and healthy vegetation — with its high NIR — renders bright red. This is the display convention you will use all semester, and once you have read the figure it is not arbitrary at all.

The constellation you will actually use

Processing levels

Imagery is distributed at defined levels, and knowing which you have determines what you must do before analysis.

• Level-1 / TOA reflectance. Geometrically corrected, radiometrically calibrated, but measuring radiation at the top of the atmosphere. It includes whatever the atmosphere contributed. Fine for a single-date visual product; unsafe for comparing dates, because the atmosphere differed.
• Level-2 / surface reflectance. Atmospherically corrected — Sen2Cor for Sentinel-2, LaSRC for Landsat. This is what you want for nearly everything, and it is what "analysis-ready data" mostly means. It also carries a quality band telling you which pixels are cloud, shadow, water or snow.
• Level-3 / composites and derived products. Aggregated over time or space: annual composites, land-cover maps, the JRC surface water dataset. Convenient, but someone else made the decisions, and you inherit their errors along with their labour.

What changes when compute moves to the data

Until recently, remote sensing meant downloading scenes and processing them locally. That model imposes hard limits: a single Sentinel-2 tile is around 600 MB, so a decade of imagery for one county is hundreds of gigabytes before you have computed anything. On a university connection this is not a delay; it is a wall.

Earth Engine, and platforms like it, invert the arrangement. The archive stays in place, your algorithm is sent to it, and only the result returns. The consequences are worth stating plainly because they reshape what questions are askable:

• Analysis over long time series stops being a data-management project and becomes a one-line filter.
• Scale becomes nearly free — a script written for a ward runs over Kenya with a changed geometry.
• The binding constraint shifts from storage and bandwidth to knowing what to ask, which is the skill this unit is actually building.

Reading. Jensen, Remote Sensing of the Environment, ch. 1–2 for the applications framing. Lillesand, Kiefer & Chipman, ch. 1 and 5. Gorelick et al. (2017), "Google Earth Engine: Planetary-scale geospatial analysis for everyone", RSE 202 — the platform's own statement of what it is for.

The one concept that matters

Your script does not process imagery. It builds a description of a computation, sends that description to Google's servers, and receives a result. The objects in your code — ee.Image, ee.Number, ee.List — are handles to things that live on the server. They are not JavaScript values, and treating them as though they were is the source of nearly every problem students have in this unit.

JavaScript · Earth Engine

// WRONG — collection.size() is an ee.Number, not a JavaScript number.
// The comparison is meaningless and this loop never runs correctly.
var total = 0;
for (var i = 0; i < collection.size(); i++) {
  total += collection.get(i);
}

// RIGHT — describe the whole operation and let the server do it.
var total = collection.size();
print(total);          // print() is one of the few calls that fetches to the client

// WRONG — a JavaScript conditional on a server-side value
if (image.get('CLOUD_COVER') < 10) { ... }

// RIGHT — express the condition server-side, as a filter
var clear = collection.filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 10));

Filter, mask, composite

Almost every Earth Engine script has the same three-stage skeleton, and once you can write it from memory you can write most of this unit.

JavaScript · Earth Engine

var aoi = ee.FeatureCollection('FAO/GAUL/2015/level1')
            .filter(ee.Filter.eq('ADM1_NAME', 'Kiambu'));

// ---- 1. FILTER: narrow the archive to what you need -------------------
var s2 = ee.ImageCollection('COPERNICUS/S2_SR_HARMONIZED')
           .filterBounds(aoi)
           .filterDate('2025-01-01', '2025-12-31')
           .filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 40));

print('scenes found:', s2.size());

// ---- 2. MASK: remove cloud, shadow and cirrus, pixel by pixel ---------
function maskS2(image) {
  var scl = image.select('SCL');        // scene classification layer
  var clear = scl.neq(3)                  // 3  cloud shadow
                 .and(scl.neq(8))         // 8  cloud, medium probability
                 .and(scl.neq(9))         // 9  cloud, high probability
                 .and(scl.neq(10))        // 10 thin cirrus
                 .and(scl.neq(11));       // 11 snow / ice
  return image.updateMask(clear)
              .divide(10000)              // SCALE FACTOR — see the warning below
              .copyProperties(image, ['system:time_start']);
}

var masked = s2.map(maskS2);              // map(), never a for loop

// ---- 3. COMPOSITE: reduce many images to one --------------------------
var composite = masked.median().clip(aoi);

Map.centerObject(aoi, 10);
Map.addLayer(composite, {bands: ['B8', 'B4', 'B3'], min: 0, max: 0.4},
             'false colour — vegetation is red');

Three notes on that script. median() is the standard compositing reducer because it is robust to the cloud that survived masking — a residual bright cloud is an outlier and the median ignores it, where mean() would not. copyProperties preserves the timestamp, without which any later time-series operation silently fails. And clip() is for display: it does not make the computation faster, and clipping early in a long chain can actually slow things down.

Reducers

A reducer collapses many values into fewer. The same objects work in three contexts, which is what makes them worth learning properly:

• Across a collection — collection.reduce(ee.Reducer.median()), or the shorthand collection.median(). Many images become one.
• Across space — image.reduceRegion({reducer: ee.Reducer.mean(), geometry: aoi, scale: 10}). Many pixels become one statistic. Always pass scale explicitly, or Earth Engine picks one for you and it is rarely what you intended.
• By zone — image.reduceRegions() with a FeatureCollection. One statistic per polygon: mean NDVI per ward, in one call.

Exporting

Nothing leaves Earth Engine until you export, and exports run as background tasks you must start from the Tasks tab.

• Export.image.toDrive — a GeoTIFF to Google Drive. Specify scale, region, crs and maxPixels. This is the route for QGIS work.
• Export.image.toAsset — keeps the result inside Earth Engine. Use this for an intermediate you will reuse; it is far faster than recomputing a long chain each session.
• Export.table.toDrive — a CSV of statistics or sample points. This is what you will export most often, and it is tiny.

Export the smallest thing that answers your question. A CSV of per-ward means is a few kilobytes; the raster it came from is gigabytes. Students routinely export a full-resolution image when they needed a table of ten numbers — and then wait an hour on a lab connection for it.

Reading. Cardille et al., Cloud-Based Remote Sensing with Google Earth Engine (2023, open access), parts F1–F3. The Earth Engine "Client vs Server" guide — short, and it is the concept the whole platform rests on.

What is already done, and what is not

Level-2 surface reflectance has had the dominant atmospheric effects removed: Rayleigh scattering, aerosol scattering and absorption, and water vapour absorption, using an atmospheric model driven by ancillary data. This is a substantial and well-validated piece of work, and you should use it.

Three things it does not handle, all of which matter in Kenya:

• Residual aerosol error. The correction estimates aerosol optical depth, and that estimate degrades over bright surfaces — exactly the arid and semi-arid land that covers most of northern Kenya. During a dust event the assumed aerosol model may simply be wrong.
• BRDF effects. Surfaces reflect differently depending on viewing and illumination geometry. Across a wide swath the view angle changes, so the same surface at the edge of a scene reads differently from the centre. Visible as a brightness gradient across a mosaic, and as a seam where two scenes meet.
• Topographic effects. Slopes facing the sun receive more irradiance than slopes facing away. Uncorrected, a single land-cover type on a hillside splits into two spectral populations, and your classifier dutifully maps them as two classes.

Topographic correction

This matters as soon as your study area has relief — the Aberdares, Mount Kenya, the Rift escarpment, the Taita Hills. The illumination condition for a sloped pixel is

The simplest correction divides by cos i, which over-corrects steep shaded slopes badly. The C-correction adds an empirical term fitted per band from the regression of reflectance on cos i, and is the standard practical choice. SCS+C is better again for forestry, because it preserves the geotropic orientation of tree canopies rather than assuming a Lambertian surface.

Diagnose the need by displaying a false-colour composite over a mountain: if the sunlit and shaded flanks of the same forest look like different cover types, you need correction. Diagnose success by plotting reflectance against cos i before and after — a good correction flattens the slope of that relationship toward zero.

Harmonising sensors

Landsat 8/9 and Sentinel-2 have similar but not identical bands: different centre wavelengths, different bandwidths, different spatial resolutions. Combining them roughly triples your usable observations, which for a cloudy tropical site is often the difference between a workable time series and no time series at all. But you cannot simply concatenate them.

1. Resample to a common grid — usually Sentinel-2's 10 m or a shared 30 m.
2. Rename bands to a common scheme so that "NIR" means the same thing regardless of source.
3. Apply cross-calibration coefficients. Published band-by-band linear transformations (Roy et al., 2016) bring one sensor onto the other's scale. The adjustments are small — a few per cent — but they are systematic, and a systematic step in a time series looks exactly like real change.
4. Verify on near-coincident acquisitions: find dates where both sensors imaged the same clear scene within a day or two, and check that the harmonised values agree.

Smoothing a time series

A per-pixel NDVI series from real imagery is ragged: gaps where cloud was masked, dips where thin cloud or shadow survived the mask, and noise. Three responses, in increasing sophistication:

• Linear interpolation across gaps. Crude, adequate for short gaps.
• Savitzky–Golay filtering. A moving polynomial fit that smooths while preserving peaks — which matters, because the peaks are the phenology you are trying to measure. A plain moving average flattens the growing-season maximum you came to find.
• Harmonic regression. Fit a constant plus sine and cosine terms at annual and semi-annual frequency. This suits Kenya particularly well: the bimodal long-rains and short-rains cycle is captured by the two harmonics, the fitted curve gives you a value on any date, and the residuals from the fit are themselves a useful anomaly signal.

Reading. Roy et al. (2016), "Characterization of Landsat-7 to Landsat-8 reflective wavelength and normalized difference vegetation index continuity", RSE 185, and the companion Sentinel-2 harmonisation paper. Cardille et al., part F4. Riaño et al. (2003) on topographic correction methods, IEEE TGRS 41(5).

Indices, and what each one is for

An index is a band ratio designed to amplify one signal and suppress others. There are hundreds; six will cover almost everything you do.

Phenology

A single date tells you little. The shape of the curve through a season tells you a great deal: when growth started, how fast, how high it peaked, when it senesced, and how much total greenness accumulated. From a smoothed series you can extract:

• Start and end of season — commonly the date at which NDVI crosses a threshold, often 20% of the seasonal amplitude, on the rising and falling limbs.
• Peak value and date.
• Integrated NDVI — the area under the curve across the season, which correlates with biomass production and hence with yield and with forage availability.
• Length of season, and in Kenya, whether there were two seasons or one — the failure of the short rains shows up as a missing second peak, and that is directly a food-security signal.

Crop types differ in phenology even when their spectra on any single date are identical. This is why a time-series feature stack classifies crops far better than a single image, and it is the basis of practically all operational crop mapping. Week 5 uses it.

From index to decision: the Vegetation Condition Index

NDVI is not comparable between places — a value of 0.4 is poor for Kericho and remarkable for Marsabit. To ask "is this area unusually stressed?", you must compare a location against its own history in the same season. That is what VCI does.

JavaScript · Earth Engine

// NDVI over a long baseline, restricted to the same calendar window
var withNDVI = function(img) {
  return img.addBands(img.normalizedDifference(['B8', 'B4']).rename('NDVI'));
};

var march = ee.ImageCollection('COPERNICUS/S2_SR_HARMONIZED')
  .filterBounds(ward)
  .filter(ee.Filter.calendarRange(3, 3, 'month'))   // same window, every year
  .map(maskS2).map(withNDVI).select('NDVI');

var ndviMin = march.min();
var ndviMax = march.max();
var current = march.filterDate('2026-03-01', '2026-04-01').median();

var vci = current.subtract(ndviMin)
                 .divide(ndviMax.subtract(ndviMin))
                 .multiply(100)
                 .rename('VCI');

Map.addLayer(vci, {min: 0, max: 100, palette: ['8B0000', 'FF8C00', 'FFFF00', 'ADFF2F', '006400']},
             'VCI, March 2026');

Reading. Huete et al. (2002) on MODIS vegetation indices, RSE 83. Kogan (1995) on VCI, Advances in Space Research 15(11). Kenya's NDMA drought bulletins — read three consecutive months and see how the remote sensing feeds an operational decision.

The class scheme comes first

Before any code, decide what you are mapping. Two constraints bind, and beginners routinely violate both.

Classes must be spectrally separable. "Maize" and "sorghum" may be indistinguishable on any single date. "Smallholder farm" and "commercial farm" differ by ownership, not reflectance, and no classifier can see ownership. If two classes cannot be told apart by the sensor, merge them or find a feature that does separate them — usually a temporal one.

Classes must be exhaustive and mutually exclusive. Every pixel must belong to exactly one class. A scheme with "forest", "cropland" and "wetland" has nowhere to put a road. The classifier will assign it somewhere regardless, silently, and your accuracy assessment will not tell you which of your classes absorbed it.

Start from an established scheme — the FAO Land Cover Classification System, or Kenya's national land-cover classes — rather than inventing one. It costs nothing and makes your product comparable with everyone else's.

Training data

This is where classification projects succeed or fail, and it takes longer than everything else combined.

• How many? A working minimum is around 50–100 pixels per class; more for spectrally variable classes. Random forest is fairly tolerant of imbalance, but a class with 20 samples against another with 2,000 will be under-predicted.
• Distributed how? Spread across the study area, not clustered where it was convenient to digitise. Training polygons drawn along one road produce a classifier that works along that road.
• Capturing what? The internal variation of each class. "Cropland" includes bare newly-planted fields, dense mid-season canopy, and senesced stubble. Train only on the green mid-season appearance and every bare field will be classified as soil.
• From where? High-resolution imagery in the Code Editor, existing verified maps, and field data. Record the source and the date of each sample — a training point digitised from 2019 imagery is not valid for a 2026 map if the land changed.

Feature stacks

You are not limited to the spectral bands of one date. A classifier can use any co-registered layer, and adding the right ones usually helps more than changing the algorithm:

• Spectral — the bands of a seasonal composite.
• Indices — NDVI, NDMI, NDBI, MNDWI. Cheap, and they encode useful non-linear combinations.
• Temporal — separate dry-season and wet-season composites, or per-pixel percentiles across the year. For crop mapping this is normally the single most valuable addition, because it is phenology that separates crop types.
• Terrain — elevation, slope, aspect. Strong for natural vegetation, which is often altitudinally zoned.
• Texture — local variance or GLCM measures. Useful for built-up areas, which are spectrally heterogeneous at fine scale.
• Radar — Sentinel-1 backscatter adds structural information the optical bands cannot see. Week 8.

JavaScript · Earth Engine

// ---- build a feature stack: two seasons, indices, terrain -------------
var dry = buildComposite('2025-01-01', '2025-03-31');
var wet = buildComposite('2025-04-01', '2025-06-30');
var dem = ee.Image('USGS/SRTMGL1_003');

var stack = dry.select(['B2','B3','B4','B8','B11','B12'])
                 .rename(['d_B2','d_B3','d_B4','d_B8','d_B11','d_B12'])
  .addBands(wet.select(['B2','B3','B4','B8','B11','B12'])
                 .rename(['w_B2','w_B3','w_B4','w_B8','w_B11','w_B12']))
  .addBands(dry.normalizedDifference(['B8','B4']).rename('d_NDVI'))
  .addBands(wet.normalizedDifference(['B8','B4']).rename('w_NDVI'))
  .addBands(dem.rename('elev'))
  .addBands(ee.Terrain.slope(dem).rename('slope'));

// ---- sample the stack at the training polygons ------------------------
var training = stack.sampleRegions({
  collection: trainingPolygons,   // must carry a 'class' property
  properties: ['class'],
  scale: 10,
  tileScale: 4                    // raise this if you hit memory limits
});

// ---- train, and hold back nothing here — validation is a SEPARATE sample
var classifier = ee.Classifier.smileRandomForest({
  numberOfTrees: 300,
  minLeafPopulation: 3
}).train({
  features: training,
  classProperty: 'class',
  inputProperties: stack.bandNames()
});

var classified = stack.classify(classifier);

// ---- which features are actually doing the work? ----------------------
print('variable importance:', classifier.explain().get('importance'));

Choosing a classifier

Classifier	Character
CART	A single decision tree. Interpretable — you can read the rules — but unstable: a small change in training data gives a different tree. Use it to understand, not to publish.
Random forest	Hundreds of trees on bootstrapped samples, voting. Robust, handles many correlated features, needs almost no tuning, gives variable importance. The default choice, and it is hard to beat.
Gradient boosting	Often marginally better than RF, at the cost of real tuning sensitivity. Worth trying once you have a working RF baseline.
SVM	Strong with limited training data and high-dimensional features. Slow on large areas, and kernel and cost parameters matter a great deal.
Minimum distance, maximum likelihood	The classical parametric methods. Still worth knowing — they appear throughout the older literature and in ENVI-based workflows you may inherit.

Do not spend the semester comparing classifiers. On most real problems the difference between random forest and gradient boosting is a percentage point or two, while the difference between poor and good training data is ten or twenty. Spend your effort where the leverage is.

Overfitting, and how to see it early

A classifier that has memorised its training data will report near-perfect accuracy on that data and fail on anything else. Three signals, available before you run a formal assessment:

• Training accuracy near 100%. Random forest will happily achieve this. It means nothing.
• Salt-and-pepper texture in the map — isolated single pixels of a class scattered through a homogeneous area. The model is responding to noise.
• Nonsense in the variable importance — a band you added carelessly dominating the model, which usually means it correlates with your training locations rather than with your classes.

Remedies: more and better-distributed training data; fewer, less correlated features; a larger minLeafPopulation; and — the one that actually settles the question — an honest validation sample, next week.

Reading. Cardille et al., part F2 on classification. Belgiu & Drăguţ (2016), "Random forest in remote sensing: A review", ISPRS Journal 114. Foody (2002) on classification accuracy, RSE 80 — read it before week 6.

The number you computed last week is not an accuracy

Random forest reports an accuracy on its training data. It is typically above 95% and it is worthless — the model has seen those pixels. Splitting your training polygons into train and test is better but still inadequate, for a reason specific to this field: your training polygons were not a probability sample. You drew them where you were confident, which is where the classes are pure and obvious. The map's errors live at boundaries, in mixed pixels, and in the ambiguous cases you avoided digitising. A holdout from your training set contains none of them.

An accuracy figure is only meaningful if the validation points were selected by a probability sampling design — every pixel in the map having a known, non-zero chance of selection. That is the requirement, and everything in this chapter follows from it.

Designing the sample

Simple random is valid but inefficient: rare classes get few points. If built-up land is 3% of your area, a 200-point random sample gives you about six built-up points, from which you can say almost nothing about that class.

Stratified random — strata being the map classes — is the standard choice. Allocate points to each class deliberately, ensuring even rare classes get enough (a common floor is 50 per class), and weight the results by class area afterwards. That weighting is the step that students omit, and it is what makes the arithmetic below different from a plain confusion matrix.

For sample size, Cochran's formula for stratified estimation of overall accuracy:

Then interpret each sample point against the best reference data you can obtain — high-resolution imagery, field visits, or both — without looking at the map's classification of that point. If you know what the map said, you will agree with it more often, and that bias is not recoverable afterwards.

Reading. Olofsson et al. (2014), "Good practices for estimating area and assessing accuracy of land change", RSE 148 — read this one properly; it is the standard the field works to. Pontius & Millones (2011), IJRS 32(15). Stehman & Foody (2019), "Key issues in rigorous accuracy assessment", RSE 231.

Two images are not enough on their own

The naive approach — classify 2000, classify 2025, compare — is the most common method in the literature and the most error-prone. Before anything else, three things must be true of your two images, and if they are not, everything you find is artefact:

• Same season. An image from March and one from August differ enormously through phenology alone. Comparing them detects the calendar, not change.
• Radiometrically consistent. Both Level-2 surface reflectance, ideally from the same sensor, with the same corrections applied.
• Co-registered. A half-pixel misregistration produces a bright halo of spurious change along every edge in the scene — field boundaries, roads, river banks. It is one of the most common sources of a change map that is mostly rubbish.

The error compounding problem

The methods

Method	How, and when
Image differencing	Subtract one date's index from the other and threshold. Simple, robust, and it avoids the compounding problem entirely because no classification is involved. Best when the change has a clear spectral direction — deforestation, burn, flood.
Image ratioing	Divide rather than subtract. Less sensitive to multiplicative differences in illumination between dates.
Change vector analysis	Treat the multi-band difference as a vector: its magnitude says how much changed, its direction hints at what kind of change. More informative than a single index difference.
Post-classification comparison	The only method that names both the from-class and the to-class, which is what a land-cover transition matrix needs. Use it when you need that, and validate the change map independently.
Time-series algorithms	Use every available observation rather than two. Far more robust. See below.

Setting a threshold

Differencing gives you a continuous surface; you must decide what counts as change. Three approaches, in increasing defensibility:

• Statistical — a fixed number of standard deviations from the mean difference, commonly 1.5 or 2. Easy, arbitrary, and it assumes the no-change population dominates.
• Histogram-based — if the difference image is bimodal, put the threshold in the trough between the modes. Better, when the histogram cooperates.
• Reference-based — take a small independent sample, interpret it, and choose the threshold that gives the balance of omission and commission your application needs. More work, and the only one you can properly defend.

Whichever you use, state it and show the histogram with the threshold marked. And recognise the choice is not purely technical: a low threshold catches more real change and more false alarms. Which error is worse depends on what happens next — a forest-loss alert that triggers a ranger patrol tolerates false alarms far better than one that triggers a prosecution.

Time-series algorithms

Using two dates throws away everything in between. The modern approach fits a model to a pixel's whole history and looks for departures.

• LandTrendr — fits straight-line segments to an annual index series and identifies breakpoints. Designed for the Landsat record; excellent at separating abrupt disturbance from slow recovery, and it dates the disturbance to the year.
• CCDC (Continuous Change Detection and Classification) — fits a harmonic model to all available observations, and flags a change when consecutive residuals exceed expectation. Uses every image rather than one per year, so it can date change to within weeks. Computationally heavy.
• BFAST — decomposes a series into trend, season and remainder, and tests for structural breaks in the trend. Strong statistical footing, and it distinguishes a genuine break from a seasonal excursion.

All three share one advantage: because they use the seasonal cycle as their baseline, a dry year does not read as deforestation. Bi-temporal methods have no way to make that distinction.

Reading. Kennedy et al. (2010) on LandTrendr, RSE 114. Zhu & Woodcock (2014) on CCDC, RSE 144. Verbesselt et al. (2010) on BFAST, RSE 114. Olofsson et al. (2014) again — its area-estimation guidance applies with particular force to change.

The problem SAR solves

Optical remote sensing fails under cloud, and much of Kenya is cloudy exactly when the interesting things happen. During the long rains, a whole month can pass without a usable Sentinel-2 observation over the highlands — and floods, planting, and rapid vegetation change all occur in precisely that window. Optical sensing is systematically blind to the events it is most needed for.

Synthetic Aperture Radar supplies its own illumination at microwave wavelengths that pass through cloud unimpeded. Sentinel-1 operates in C-band at 5.405 GHz — a wavelength of about 5.6 cm — and images regardless of cloud, day or night, every six to twelve days.

What backscatter measures

SAR does not measure reflected sunlight. It transmits a pulse and measures how much energy returns, reported as the backscatter coefficient σ⁰ in decibels. Three surface properties dominate:

• Roughness, relative to the wavelength. A surface smooth at the 5.6 cm scale reflects the pulse away like a mirror — specular reflection — and almost nothing returns. Calm open water is the extreme case, which is why water appears very dark in SAR, typically below about −15 dB in VV against −5 to −10 dB for most land. This single fact is the basis of nearly all operational flood mapping.
• Moisture. The dielectric constant rises steeply with water content, so wetter soil and vegetation return more energy. Useful for soil moisture; also a confounder, because a wet field and a rough field can look alike.
• Structure. Volume scattering from a canopy, and double-bounce from vertical structures meeting the ground — building walls, flooded tree trunks, rice stems — which returns energy strongly back toward the sensor. Urban areas are bright in SAR for this reason.

Geometry, and its three distortions

The practical consequence: in mountainous terrain — the Aberdares, Mount Kenya, the Rift escarpments — parts of every SAR scene are unusable, and a shadow region is not water even though it is as dark as water. Terrain-corrected products handle the geometry, but they cannot invent data where none was collected. Mask layover and shadow explicitly; Earth Engine's Sentinel-1 collection is terrain-corrected but does not mask them for you.

Polarisation

Sentinel-1 in its standard mode transmits vertically and receives both vertically (VV) and horizontally (VH). The pair carries structural information:

• VV — co-polarised. Sensitive to surface roughness and moisture. The band for water and flood mapping.
• VH — cross-polarised. Energy only changes polarisation through multiple scattering, so VH responds to volume — canopy structure. The band for vegetation and crop structure.
• VH/VV ratio — separates volume scattering from surface scattering, and is often the most informative single feature for distinguishing crop types and growth stages.

Speckle

SAR images have a grainy salt-and-pepper texture that is not noise in the ordinary sense. It arises from coherent interference among the many scatterers within a resolution cell, and it is deterministic — image the same scene twice under identical geometry and you get the same speckle pattern.

It still has to be reduced before most analysis. Multi-looking averages several independent looks, trading resolution for radiometric quality. Adaptive filters — Lee, refined Lee, Frost — smooth homogeneous areas while preserving edges. For a threshold-based flood map, a modest speckle filter makes the difference between a clean water mask and a shredded one. Do not over-filter: aggressive smoothing removes small water bodies along with the speckle.

JavaScript · Earth Engine

// Sentinel-1 GRD in Earth Engine arrives terrain-corrected and in dB.
var s1 = ee.ImageCollection('COPERNICUS/S1_GRD')
  .filterBounds(aoi)
  .filter(ee.Filter.eq('instrumentMode', 'IW'))
  .filter(ee.Filter.listContains('transmitterReceiverPolarisation', 'VV'))
  .filter(ee.Filter.eq('orbitProperties_pass', 'DESCENDING'))  // keep geometry constant
  .select('VV');

var before = s1.filterDate('2026-03-01', '2026-03-25').median();
var after  = s1.filterDate('2026-04-20', '2026-04-30').median();

// speckle reduction — enough to stabilise the threshold, not enough to erase ponds
var smooth = function(img) {
  return img.focalMedian(50, 'circle', 'meters');
};

// water is specular: very low backscatter. Threshold, then remove pre-existing water.
var THRESH = -16;                          // dB — CHECK THIS against your own histogram
var waterAfter  = smooth(after ).lt(THRESH);
var waterBefore = smooth(before).lt(THRESH);
var flooded = waterAfter.and(waterBefore.not());

// exclude permanent water and steep terrain, where shadow mimics water
var jrc   = ee.Image('JRC/GSW1_4/GlobalSurfaceWater').select('seasonality');
var slope = ee.Terrain.slope(ee.Image('USGS/SRTMGL1_003'));
flooded = flooded.updateMask(jrc.lt(5)).updateMask(slope.lt(5));

var areaKm2 = flooded.multiply(ee.Image.pixelArea()).divide(1e6)
  .reduceRegion({reducer: ee.Reducer.sum(), geometry: aoi, scale: 20, maxPixels: 1e10});
print('flooded area, km²:', areaKm2);

Reading. Richards, Remote Sensing with Imaging Radar (2009), ch. 1–3. The ESA Sentinel-1 user guide. Cardille et al., part F3 on SAR in Earth Engine. Moreira et al. (2013), "A tutorial on synthetic aperture radar", IEEE GRSM 1(1) — the best single introduction available.

Land surface temperature

A thermal sensor measures emitted radiance, from which brightness temperature follows by inverting the Planck function. Converting that to the actual surface temperature requires emissivity — how efficiently a surface radiates compared with a perfect black body. Water is near 0.99, dense vegetation about 0.98, bare soil 0.92–0.96, and concrete and metal roofing lower still and highly variable.

Get emissivity wrong and your temperature is wrong: an error of 0.01 in emissivity translates to roughly 0.5–0.7 K. Most operational approaches estimate emissivity from NDVI via a vegetation-cover fraction, which works reasonably over vegetated land and poorly over the mixed urban surfaces where you most want the answer.

Note also what LST is and is not. It is the radiometric temperature of the surface — the roof, the road, the leaf canopy — not the air temperature a person experiences. On a sunny afternoon a tarmac surface can read 20 K above the air temperature two metres above it. Reporting LST as "temperature" without qualification is a real misrepresentation, and it appears in published work.

Urban heat islands

Cities are hotter than their surroundings: dark impervious surfaces absorb more shortwave radiation, there is little vegetation to cool by transpiration, and the urban geometry traps longwave radiation. The measurement is straightforward and the design decisions are where the difficulty lies.

• Choosing the rural reference is the whole method. It must be genuinely comparable — similar elevation, similar background land cover, close enough that regional climate is the same. An irrigated farm as your reference produces a spuriously large heat island; a bare quarry produces a spuriously small one, or a negative one.
• Time of day matters enormously. Landsat overpasses Kenya at around 10:30 local time, well before the afternoon peak. Daytime and night-time heat islands have different magnitudes and different physical causes, and a satellite that only ever sees mid-morning cannot tell you about either extreme.
• Relate it to something. The useful analysis is not the temperature map but the relationship — LST against NDVI, against impervious fraction, against distance from the centre. That is what supports a recommendation about tree planting or roofing materials.

Evapotranspiration

ET is the largest term in the water balance of most Kenyan catchments and the one hardest to measure directly. Satellite methods exploit the surface energy balance: net radiation is partitioned between ground heat flux, sensible heat and latent heat, and latent heat is evapotranspiration. Because a well-watered surface stays cool through transpiration while a water-stressed one heats up, surface temperature carries the signal.

• SEBAL and METRIC anchor the energy balance at two extreme pixels within the scene — a "hot" dry pixel with no ET and a "cold" wet pixel at maximum ET — and interpolate between. Accurate, but the operator chooses those anchor pixels, and the answer depends on that choice.
• SSEBop uses pre-defined boundary conditions rather than scene-specific anchors, which makes it reproducible and operational at the cost of some local accuracy.

The applications are concrete and Kenyan: irrigation scheduling in the Rift Valley horticulture schemes, water allocation in the Ewaso Ng'iro basin, and crop water productivity assessment. FAO's WaPOR portal publishes ET for Africa and is worth knowing.

Surface water

The JRC Global Surface Water dataset is a finished product built from 40 years of Landsat, and it saves you an enormous amount of work. It provides, at 30 m: occurrence (the percentage of observations in which each pixel was water), change intensity, seasonality, recurrence, and transitions between permanent, seasonal and no water.

Kenya offers unusually good material here. The Rift Valley lakes — Baringo, Nakuru, Naivasha, Turkana — have undergone dramatic and well-documented level changes, with substantial rises since about 2010 that displaced settlements and flooded infrastructure. The occurrence layer distinguishes the historically permanent lake from the recently inundated margin immediately, and that distinction is exactly what a planning question needs.

Atmospheric composition

Sentinel-5P's TROPOMI instrument measures NO₂, CO, SO₂, CH₄, O₃ and aerosol index daily at roughly 5.5 × 3.5 km. Three limitations to state whenever you use it:

• It measures a column — the total through the whole atmosphere — not a ground-level concentration. The relationship between column NO₂ and what a person breathes depends on the vertical distribution, which varies.
• The pixel is kilometres across. It resolves a city, not a road.
• Cloud blocks retrieval, so the record is patchy, and the gaps are not random.

Within those limits it is genuinely useful: NO₂ over Nairobi shows a clear weekday–weekend cycle that tracks traffic, and the aerosol index picks up biomass burning across the region during the dry season.

Reading. The USGS Landsat Collection 2 Level-2 Science Product guide, for the scale factors and the surface temperature algorithm. Pekel et al. (2016), "High-resolution mapping of global surface water and its long-term changes", Nature 540. Senay et al. (2013) on SSEBop, JAWRA 49(3).

"Ground truth" is a misleading phrase

Field data is not truth. It is another observation, with its own errors: the GPS fix, the observer's judgement, the date it was collected, the definition of the class in the observer's head. Two competent field workers will disagree on perhaps 5–15% of land-cover calls at boundaries and in mixed cover — and that disagreement rate is a ceiling on any accuracy you can demonstrate. If your interpreters agree only 90% of the time, you cannot demonstrate 95% map accuracy, because you have no instrument capable of measuring it.

The honest term is reference data, and the honest practice is to report how it was collected, by whom, when, and with what agreement between interpreters.

Designing a field campaign

• Sample by design, not by road. The single biggest weakness in most student and much professional field data is that everything was collected within 200 m of a passable track. That is a biased sample of the landscape and it biases everything computed from it. If access forces you to sample near roads, say so explicitly and discuss the direction of the bias.
• Match the timing. Land cover observed in August cannot validate a March image in an agricultural landscape. For crops, timing is everything.
• Record the plot, not just the point. Note the homogeneity of the surroundings — a point in a 5-hectare uniform field is far more useful than one at a boundary.
• Record uncertainty. Let observers mark a call as uncertain rather than forcing a choice. Those records are informative, and discarding them silently biases the assessment toward easy cases.
• Use a structured digital form. ODK or KoboToolbox on a phone: enforced field types, automatic GPS capture, photographs, timestamps, and no transcription step. Both work offline and sync later, which matters in the field.

Positioning

Method	Accuracy	Adequate for
Smartphone GNSS	3–5 m	30 m Landsat pixels, and 10 m Sentinel-2 in homogeneous cover
Mapping-grade receiver	0.5–2 m	10 m pixels near boundaries; small features
RTK / PPK	~2 cm	Very-high-resolution validation; individual trees; structures

Match the method to the pixel. A 3 m smartphone error on a 30 m pixel is a tenth of a pixel and irrelevant; the same error on 3 m PlanetScope imagery puts you in the wrong pixel entirely. And record the accuracy the device reports for each point — under canopy or between tall buildings it degrades sharply, and knowing which points are weak lets you weight or exclude them later.

Scale mismatch

A Landsat pixel is 30 × 30 m — 900 m². A typical field plot might be 10 × 10 m, about one ninth of that. You are comparing a measurement of part of a pixel against a value integrated over all of it, and in a smallholder landscape with fields smaller than a pixel, most pixels are mixtures.

This is not a solved problem, but it is a manageable one. Sample in patches large enough to contain a full pixel with margin; record the fractional composition of a plot rather than a single label where you can; or move to a finer sensor when the landscape demands it. Above all, state the mismatch in your methods — a reader needs to know that your 30 m map was validated with 10 m plots in a landscape of half-hectare fields.

Communicating uncertainty

A county planner does not want a confusion matrix. They want to know whether they can act on the map. Translate:

• Say what the number means. Not "producer's accuracy 62%" but "the map finds about three fifths of the built-up land; roughly two fifths is missed, so treat this as a minimum estimate of urban extent."
• Give the interval, always. "109 ± 31 km²" is honest. "109 km²" implies a precision you do not have.
• Say where the map should not be used. Which classes are unreliable, which areas had persistent cloud, which season the map represents.
• Say what would improve it, and what that would cost. This turns a limitation into a decision the client can make.

Ethics

Earth observation watches people who did not consent and mostly do not know. That is worth sitting with rather than passing over, and four questions arise directly in the projects you will build.

Who is being observed, and who benefits?

Mapping informal settlements can direct services to people who need them, and it can support eviction. The imagery is identical; the difference is who commissioned the map and what happens next. You are entitled to ask that question, and in professional practice you should.

Resolution is a policy choice

At 30 m you map settlement extent. At 30 cm you map individual structures and can count them. The finer product is more useful and more dangerous, and choosing the resolution is choosing what becomes possible. Default to the coarsest resolution that answers the question.

Accuracy has asymmetric consequences

A crop map that under-detects smallholder plots may exclude those farmers from an input subsidy. A forest-loss map with high commission error may implicate the wrong landholder. When errors fall unevenly on people with different power to contest them, the class-level accuracies in week 6 are not a technical annex — they are the fairness analysis.

Open data cuts both ways

Publishing your map openly is usually right: it enables verification, reuse, and accountability. But a map of water points during a resource conflict, or of a wildlife population under poaching pressure, is a targeting aid. Kenya has open data commitments and a Data Protection Act; know the framework, and know that legal compliance is a floor rather than the whole of the question.

Reading. Stehman & Foody (2019), RSE 231, on reference data quality. Kenya's Data Protection Act (2019). Kwan (2016) on algorithmic geographies and the ethics of geospatial data, Annals of the AAG 106(2).

Where Earth observation actually gets used

Agriculture and food security. Crop type and area, condition monitoring, yield forecasting, drought early warning. In Kenya this runs through NDMA's bulletins and FEWS NET, and it is directly operational — it triggers resource allocation. The hard parts are smallholder field sizes below the pixel and persistent cloud during the growing season, which is why week 8 exists.

Forestry and carbon. Deforestation and degradation monitoring, REDD+ measurement, reporting and verification. Carbon finance requires accuracy assessments that meet published standards — which is why week 6 is the centre of this unit rather than an afterthought. A forest-change map without a probability-sample accuracy assessment and bias-adjusted areas has no financial value at all.

Urban planning. Growth monitoring, informal settlement mapping, heat islands, green space, infrastructure planning. Kenyan cities are growing faster than surveys can track, which makes EO the only practical instrument, and raises every question in week 10.

Disaster response. Flood extent, landslides, fire, drought. The International Charter "Space and Major Disasters" provides free tasking after a declared disaster; response timelines are hours to days, which shapes every methodological choice toward the robust and the fast.

Water resources. Surface water extent, lake levels, evapotranspiration, irrigation monitoring. Kenya's Rift Valley lake rises since 2010 are a well-documented case with real displacement consequences.

From a map to a service

Most student projects produce a map. Operational use needs several things a map does not have, and knowing this is part of what distinguishes a graduate:

• Repeatability. It must run again next season without you. That means documented code, versioned inputs, and no manual steps you did once and forgot.
• Latency. A flood map delivered in three weeks is a historical record. Know the deadline the decision faces.
• A stated accuracy, produced the same way each cycle, so that change in the product can be distinguished from change on the ground.
• A delivery route. A GeoTIFF on your laptop is not a service. The Web Mapping unit is the other half of this.
• Someone who will act on it, and who has been involved early enough that the product answers their question rather than yours.

What to carry out of this unit

The platforms will change. Earth Engine is roughly a decade old; the sensors you have used will be superseded; the classifiers will be replaced by things that work better and explain themselves less. What does not change is the structure of the problem: an instrument measuring reflected or emitted radiation, an atmosphere in the way, a pixel that averages a piece of a world that does not respect pixel boundaries, and a person who will act on the map.

And one habit, which is the reason week 6 sits at the centre of this reader. A classified image is not a map until it has been validated with a probability sample. The classification is the easy part, and it now takes fifteen lines of code that a language model will write for you in seconds. The validation is the part that makes the result mean something — and it is the part nobody can do for you, because it requires going and looking.

Reading. Cardille et al., parts A1–A3 on applications. Olofsson et al. (2014) once more. The GFOI Methods and Guidance Documentation for the REDD+ reporting context.

The Code Editor is JavaScript. If you have taken Web Mapping you already have the language; if not, the subset you need is small. Work through these before week 2, without help of any kind — no notes, no search, no AI assistant. The point is to find out what you have.

The ten tasks

1. Declare a variable holding the string "Kiambu" and print it to the console.
2. Write a function that takes a number and returns it multiplied by 0.0001. Call it with 4500.
3. Declare an object with properties name, zoom and bands (an array of three strings). Print the second band.
4. Explain what method chaining does in collection.filterDate(a, b).filterBounds(g).median(), and in what order the operations apply.
5. Write a template literal producing "Found 42 scenes" from a variable n.
6. Explain the difference between var x = 5; and var x = ee.Number(5);.
7. Why does the following not work, and what should you write instead?
   if (image.get('CLOUD_COVER') < 20) { print('clear'); }
8. Why does this loop fail?
   for (var i = 0; i < collection.size(); i++) { ... }
9. Rewrite this using map(): "add an NDVI band to every image in a collection".
10. You call image.reduceRegion({reducer: ee.Reducer.mean(), geometry: aoi}) and get an unexpected number. What did you omit?

Tasks 1–5 are ordinary JavaScript. Tasks 6–10 are the Earth Engine concept, and getting them wrong now is completely normal — but getting them wrong in week 5 will cost you a practical.

Five things that will actually bite you

• Server objects are not values. You cannot compare an ee.Number with <, loop over an ee.List with for, or print one with console.log. Use ee.Filter, map(), and print().
• print() is expensive and limited. It fetches to the client and will fail on large objects. Never call it inside a map().
• Always pass scale to reducers. Omit it and Earth Engine chooses one — usually the projection of the first band, which is rarely what you meant, and the number will be wrong without complaint.
• Scale factors differ per product. Sentinel-2 divides by 10000; Landsat Collection 2 has a multiplier and an offset. Reflectance outside 0–1 means you have skipped one.
• copyProperties preserves the timestamp. Forget it inside a mapped function and every later time-series operation fails, often silently.

Where to go

• Cardille et al., Cloud-Based Remote Sensing with Google Earth Engine (2023) — free, open access, and the set text for this unit. Part F1 is the fastest route in.
• The Earth Engine "Client vs Server" guide — two pages, and it is the concept everything else rests on.
• The Earth Engine tutorials and Developer Guide — well written, and the Code Editor's autocomplete works well enough to explore with.
• MDN "JavaScript first steps", if the gap is the language rather than the platform.
• Awesome Earth Engine and the Earth Engine community catalog — worked scripts for most of what this unit covers.

This sheet is supplied in the CATs and the final examination.

Sentinel-2 MSI

Landsat 8/9 equivalents: B2 blue, B3 green, B4 red, B5 NIR, B6 SWIR1, B7 SWIR2, B10 thermal. Note that NIR is B5 on Landsat and B8 on Sentinel-2 — the most common band-mixing error there is.

Scale factors — check these every time

Product	Conversion
Sentinel-2 L2A reflectance	DN / 10000
Landsat C2 L2 reflectance	DN × 0.0000275 − 0.2
Landsat C2 L2 surface temperature	DN × 0.00341802 + 149.0 → K
Sentinel-1 GRD in Earth Engine	already dB — do not rescale

Sanity checks: surface reflectance ∈ [0, 1]; NDVI ∈ [−1, 1]; LST in Kenya ∈ roughly [10, 60] °C; Sentinel-1 VV σ⁰ ∈ roughly [−25, 0] dB.

Indices, in Sentinel-2 bands

Accuracy and area

Earth Engine, minimum viable

JavaScript · Earth Engine

ee.ImageCollection(id).filterBounds(g).filterDate(a, b)
  .filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 30))
collection.map(fn) · collection.median() · collection.qualityMosaic('NDVI')
image.select(bands).rename(names) · image.updateMask(mask)
image.normalizedDifference(['B8','B4'])       // any normalised difference
image.addBands(other) · image.clip(geom)
image.reduceRegion({reducer, geometry, scale, maxPixels})   // scale is REQUIRED
image.reduceRegions({collection, reducer, scale})
image.sampleRegions({collection, properties, scale})
image.stratifiedSample({numPoints, classBand, region, scale})
ee.Classifier.smileRandomForest(n).train({features, classProperty, inputProperties})
classified.errorMatrix('reference', 'classification')
ee.Image.pixelArea()                          // for area sums
Export.image.toDrive({image, region, scale, crs, maxPixels})
Export.table.toDrive({collection, fileFormat: 'CSV'})

Supplied locally

• Training and validation polygons for two study areas, so a practical can proceed while your own collection is still in progress.
• Pre-exported GeoTIFF composites for the key weeks — the offline fallback for when the lab network fails.
• Field data from previous cohorts' campus campaigns, with the interpreter-agreement statistics attached.
• Kenyan county and sub-county boundaries, cleaned, for use where GAUL is out of date.

Earth Engine collections carry the licence terms of their originating agency — Copernicus data is free and open with attribution; Landsat is public domain; CHIRPS and WorldPop have their own citation requirements. Cite the dataset, not just the platform, and cite Gorelick et al. (2017) for Earth Engine itself.

EGS 2403 Remote Sensing Applications · Course reader, edition 1.0 · Jomo Kenyatta University of Agriculture and Technology · September 2026. Corrections and suggestions are welcome and will be credited in the next edition.

This unit teaches Earth Engine. Earth Engine is a product, owned by one company, offered under terms that company sets and can change. It is reasonable to ask what happens to your skills if it does — and the honest answer is worth more to you than the platform is.

The risk is not hypothetical

Google has changed the terms of geospatial products before, with real consequences for people who had built on them. In 2018 the Google Maps Platform moved to a pay-as-you-go model with a monthly credit; a great deal of academic, NGO and small-business mapping that had run free for years suddenly carried a bill, and some of it simply stopped. Earth Engine itself moved to a commercial footing in 2023, with paid tiers for commercial users alongside continued free access for research, education and non-profit work. Free academic access remains, and there is no signal that it is going away — but it is a policy, not a guarantee, and policies are revised.

Set against that: the value is real. In a lab where the connection is unreliable and the machines are modest, a platform that transfers no imagery at all and does the computation elsewhere is not a convenience, it is the difference between doing this work and not doing it. That is why this unit teaches it.

What actually transfers

Nearly everything. Strip away the API and the workflow in every chapter of this reader is the same five operations:

1. Search an archive by space, time and metadata
2. Mask the pixels you cannot use
3. Reduce many observations to one composite, or to a time series
4. Compute band arithmetic and derived features
5. Classify, validate, and estimate area with an interval

None of that is Google's. The sensor physics of week 1, the index choices of week 4, the training design of week 5, the whole of week 6, the change-detection logic of week 7, the radar geometry of week 8 — all of it is platform-independent, and all of it is the part that takes a semester to learn. What is Google-specific is the syntax, and syntax is the cheap part. A competent analyst moves between these environments in a week.

The open alternative, named concretely

The cloud-native geospatial stack does the same job with open standards and open tools:

• STAC — SpatioTemporal Asset Catalog, a JSON specification for describing and searching imagery archives. Replaces ee.ImageCollection(...).filter(...). Public endpoints include Element 84's Earth Search over the AWS Sentinel-2 archive (no account needed) and Microsoft's Planetary Computer.
• COG — Cloud-Optimised GeoTIFF. Internally tiled with overviews, so an HTTP range request fetches only the window and zoom level you need. This is what stops "no downloads" from being unique to Earth Engine.
• odc-stac or stackstac — load STAC search results straight into an xarray cube.
• xarray + dask — labelled, lazy, chunked arrays. Nothing is read until you ask for a result, which is the same deferred-execution idea Earth Engine uses.
• rioxarray / rasterio — raster I/O, reprojection, writing GeoTIFFs.
• openEO — a standardised API for Earth observation processing, implemented by the EU's Copernicus Data Space Ecosystem among others. This is the hedge worth knowing about: it is a specification, so code written against it is not tied to any one provider.

Side by side

Week 2's central script, in both environments. Read them together — the operations line up one for one.

JavaScript · Earth Engine

var s2 = ee.ImageCollection('COPERNICUS/S2_SR_HARMONIZED')
  .filterBounds(aoi)
  .filterDate('2025-01-01', '2025-12-31')
  .filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 40));

var masked = s2.map(function(img) {
  var scl = img.select('SCL');
  var clear = scl.neq(3).and(scl.neq(8)).and(scl.neq(9))
                 .and(scl.neq(10)).and(scl.neq(11));
  return img.updateMask(clear).divide(10000);
});

var composite = masked.median();
var ndvi = composite.normalizedDifference(['B8', 'B4']);

Export.image.toDrive({image: ndvi, region: aoi, scale: 10});

Python · STAC + COG

import pystac_client, odc.stac, rioxarray

bbox = [36.6, -1.3, 37.2, -0.9]        # Kiambu

# 1. SEARCH — STAC replaces ee.ImageCollection().filter()
catalog = pystac_client.Client.open("https://earth-search.aws.element84.com/v1")
items = catalog.search(
    collections=["sentinel-2-l2a"],
    bbox=bbox,
    datetime="2025-01-01/2025-12-31",
    query={"eo:cloud_cover": {"lt": 40}},
).item_collection()
print(f"{len(items)} scenes found")

# 2. LOAD — lazily, into an xarray cube backed by dask.
#    Nothing is downloaded yet: COG range requests happen on demand.
ds = odc.stac.load(
    items,
    bands=["red", "nir", "scl"],
    resolution=10,
    bbox=bbox,
    chunks={"x": 2048, "y": 2048},
)

# 3. MASK — the same SCL classes as the Earth Engine version
clear = ~ds.scl.isin([3, 8, 9, 10, 11])
ds = ds.where(clear) / 10000          # the scale factor does not go away

# 4. COMPOSITE and 5. BAND MATH
composite = ds.median(dim="time")
ndvi = (composite.nir - composite.red) / (composite.nir + composite.red)

# only NOW does anything actually transfer or compute
ndvi.compute().rio.to_raster("ndvi_kiambu_2025.tif")

Two things to notice. The shape is identical — search, mask, composite, band maths, write — and both environments defer execution until you ask for a result, so the mental model transfers directly. And the scale factor is still there in the Python version, because it is a property of the Sentinel-2 product, not of the platform. Every trap in this reader is a trap in both stacks.

The honest comparison

Note the row that people forget: the open stack does not remove the dependency on someone's cloud, it moves it. Earth Search runs on AWS; the Planetary Computer is Microsoft's. What it removes is lock-in — your code is not written against a proprietary API, so switching provider is a changed URL rather than a rewrite.

Reducing your exposure while you use it

• Export your intermediates. A composite or a classified map living only as an Earth Engine asset is trapped. Export the ones that cost real computation as GeoTIFFs you hold yourself.
• Keep the science separate from the API. Write your index definitions, thresholds, class schemes and validation design as documented decisions, not as buried lines of platform-specific code. Those are the assets; the API calls are scaffolding.
• Know geemap. It drives Earth Engine from Python, which puts your work in the same language and notebook environment as the open stack — a half-step that makes the eventual port much shorter.
• Watch openEO and the Copernicus Data Space Ecosystem. A European, standards-based, publicly funded alternative is a genuinely different kind of dependency from a single company's product.

Reading. The STAC specification and the pystac-client documentation. The Cloud-Native Geospatial Foundation's introductory material. The openEO API documentation and the Copernicus Data Space Ecosystem. Gorelick et al. (2017) for what Earth Engine set out to be, read alongside Google's current Earth Engine terms of service — the comparison is itself instructive.