NDVI Monitoring

NDVI monitoring is the canonical remote sensing workflow: track vegetation condition through time and flag where greenness has changed in a way that may signal stress, recovery, a seasonal shift, or land management activity. This page walks the whole path — from framing the question to interpreting a result — rather than treating the index as a single button press. The reasoning here lives in the imagery and in the decisions you make about it, so it holds whatever platform you eventually compute on: a browser environment like Google Earth Engine is one convenient way to try each step, and a Python stack (rasterio, xarray, geopandas) is another, but neither changes what the workflow is doing or why.

Frame the monitoring question first

A monitoring workflow is only as good as the question it answers, and that question fixes every later choice. Decide the area of interest (a field, a management unit, a watershed, a city), the comparison you care about (this season versus last, current versus a multi-year baseline, before versus after a known event), and the decision threshold — how large a change has to be before it is worth a human looking. Name the season and cadence too: vegetation is a moving target, so “greener than expected” only means something relative to an explicit reference period. Writing these down turns a vague “watch the crops” into a testable specification, and it is the difference between a map that informs a decision and a colourful picture.

Acquire suitable imagery

NDVI needs red and near-infrared reflectance, so the first practical step is choosing an optical sensor whose bands, revisit, and spatial detail fit the question. The tradeoffs here are exactly those the Resolution concept lays out: a finer pixel resolves a small field but narrows coverage and often lengthens revisit, while a coarser, more frequent sensor tracks a region’s rhythm but blurs individual parcels. Temporal cadence matters as much as pixel size for monitoring — you cannot detect a two-week stress event with a monthly clear-sky record. Confirm that the source delivers a red and NIR band with a usable Spectral Bands response, and prefer calibrated surface reflectance over raw digital numbers so values mean the same thing on every date, as the Digital Imagery concept explains. Two open archives usually answer this: reach for Sentinel-2 when the comparison sits inside recent seasons, and Landsat when the baseline you named reaches back years or decades. Selecting the actual dates is a STAC catalog query, which is also what makes the input set of a monitoring run something you can state rather than something you assembled by hand. The longer the baseline you named, the more scenes that query returns, and past a certain point the honest answer is to run the comparison where the archive already sits rather than pulling it down — which is what a hosted catalog such as the Microsoft Planetary Computer offers for the multi-year version of this workflow.

Prepare the imagery before you measure

Preprocessing is where most monitoring errors are actually prevented. Clouds, shadows, haze, and snow all corrupt an optical measurement, and an unmasked cloud edge is a classic source of fake vegetation change — so apply a quality or cloud mask to every date before computing anything, following the Cloud Masking concept. Make sure the dates share a coordinate reference and are aligned to the same grid; a half-pixel misregistration masquerades as change at every parcel boundary. Where the question is about specific units, bring in a land-cover or boundary mask so you compare vegetation to vegetation rather than averaging in roads, water, or bare soil. The goal of this stage is a stack of dates that are directly comparable — same footprint, same calibration, same masking rules — so that any later difference reflects the ground and not the processing.

Compute NDVI consistently across dates

NDVI is the normalised difference of near-infrared and red reflectance, (NIR - Red) / (NIR + Red), and the reason it works is the vegetation signature described in the Spectral Bands concept: healthy leaves reflect strongly in the near-infrared and absorb in the red, so the ratio rises with green, photosynthetically active cover and falls over stressed, senescent, or non-vegetated surfaces. The discipline that makes it a monitoring index rather than a one-off snapshot is consistency: compute it the same way, from the same bands and the same reflectance product, on every date. An NDVI built from uncalibrated values on one date and surface reflectance on another produces a “change” that is really a change of method. Because it is a bounded ratio, NDVI also partly cancels differences in illumination and view angle between dates, which is one reason index-based comparison is more stable than comparing raw bands.

Summarize and compare against a baseline

A per-pixel NDVI image is data, not yet an answer. Summarise it to the unit your question named — mean or median NDVI by field, grid cell, watershed, or ecosystem patch — so the result is a number a stakeholder can act on and rank. Then compare each date against an explicit reference: a same-season period from prior years, a rolling average, or a known pre-event condition. This is the multi-temporal reasoning the Time Series concept develops, and the departure you compute — current minus baseline — is an anomaly, the building block of the Change Detection concept. Deciding against what you compare is a real modelling choice: a dry year looks like widespread stress against a wet-year baseline and looks normal against a long-term one, and only the question decides which framing is honest.

Separate real signal from noise

Not every dip in NDVI is a story. Before believing an anomaly, rule out the ordinary explanations: normal phenology (crops green up and senesce on schedule), irrigation and management timing, residual cloud or shadow the mask missed, snow, and step changes introduced by switching between sensors mid-record. The Cloud Masking and Time Series concepts both matter here, because a sparse or seasonally-biased set of clear observations can manufacture apparent change on its own. The practical habit is to treat an anomaly as a hypothesis and check whether it survives the obvious confounders before it is escalated for review.

Produce outputs, interpret, and make it reproducible

The deliverables of a monitoring run are usually a set: an anomaly map, a time-series chart per unit, and a ranked list of areas that crossed the threshold and warrant a closer look. Interpret them with domain context — the same caution the Classification Basics concept applies to any labelled output — and state the uncertainty: which dates were thin, which units had few clear pixels, and where the mask was doing heavy work. Finally, make the run reproducible, which is the outcome that separates a durable workflow from a one-off. Record the area of interest, the exact dates and sensor, the masking and reflectance products, the summary unit, the baseline definition, and the decision threshold. That record is also the handover point: when monitoring moves from an occasional run to a scheduled one, those same parameters are what a raster processing pipeline is configured from. With those written down, the same analysis can be re-run next month, audited by someone else, or ported from one platform to another without quietly changing what it measures — which is the whole point of a concept-first workflow.