Infrastructure Monitoring

Infrastructure monitoring is a repeated-observation workflow: watch corridors and assets — power lines, pipelines, roads, rail, dams — for change or exposure in the surrounding land that may warrant an inspection, maintenance visit, or risk review. What makes it a workflow rather than a single map is the word monitoring: the deliverable is not a snapshot of an asset but a comparison over time around it, run on a cadence, that turns a vast network no crew can walk into a short, ranked list of segments worth looking at. This page walks the whole path from framing the monitoring goal to producing that list. As with every workflow here the reasoning lives in the imagery and the choices you make about it, so it holds on any platform: a browser environment like Google Earth Engine is one convenient way to try each step, and a Python stack (STAC, rasterio, xarray) is another, but neither changes what the workflow is doing or why.

Frame the asset, the corridor, and the action threshold

A monitoring workflow is only as useful as the decision it triggers, so fix that decision first. Name the asset class and its corridor geometry — a buffer around a line, a polygon around a facility — because everything downstream is measured inside that zone rather than across the whole scene. Set the cadence (how often you re-observe, driven by how fast the relevant change happens) and the change types of interest: vegetation encroaching on a right-of-way, new construction inside a protected buffer, erosion or surface disturbance, flood or fire exposure, or ground-movement indicators near a slope. Then set an action threshold — how much change, or how much exposure, escalates a segment to a human. Naming these turns “keep an eye on the corridor” into a testable specification with a geometry, a cadence, and a trigger, which is the difference between an alert queue an inspector trusts and a wall of noise they learn to ignore.

Assemble asset geometry and comparable imagery

Two inputs anchor this workflow: where the assets are, and imagery you can compare across dates. Asset locations and corridor buffers must be accurate, because a right-of-way offset by a few metres attributes change to the wrong segment or misses it entirely — align every layer to one grid following the Coordinate Systems concept, and treat the Raster vs Vector join between the vector network and the raster scenes as a first-class step, not an afterthought. For imagery, let the smallest change you must catch drive sensor choice through the tradeoffs the Resolution concept lays out: a finer pixel resolves a single new structure or a narrow encroachment but revisits less often, while a coarser, more frequent sensor tracks a long corridor’s rhythm but blurs asset-scale detail. Prefer calibrated surface reflectance so a value means the same thing across dates, as the Digital Imagery concept explains, and lean on the Spectral Bands that separate vegetation, bare ground, and built surfaces. For most corridors that means Sentinel-2 for the repeat observations the cadence depends on, with NAIP for the moments when a flagged segment has to be interpreted at asset scale rather than merely detected. Where cloud or the need to sense ground and structure movement defeats optical imagery, radar is the complement: SAR sees through cloud and its phase is the basis for the interferometric methods used to flag possible slope or subsidence movement near critical assets. Gather the context layers now too — terrain from a DEM, land cover, hazard maps, and any maintenance or inspection records that later serve as ground truth.

Build repeatable observations around each asset

The heart of monitoring is comparability: an alert only means something if the before and after differ because the ground changed, not because the processing did. Screen every optical date for cloud, shadow, and haze before comparing anything — an unmasked cloud edge over a right-of-way reads as a spurious disturbance — following the Cloud Masking concept. Then fix a repeatable recipe and apply it identically every cycle: the same corridor buffer, the same seasonal window, the same masking rules, and an explicit comparison pairing (this pass versus the last, or versus a stable baseline). Summarising within the buffer rather than the whole scene keeps the measurement focused on the asset and cuts the data volume enough to run the network on a schedule. The goal of this stage is a stack of asset-centred observations that are directly comparable — same footprint, same calibration, same masking — so any later difference reflects the corridor and not the method. Once the cadence is real the recipe stops being something a person runs and becomes something that has to survive one unusable date, or one segment that fails, without putting the whole network back through the cycle. That operating problem is what the raster processing pipeline note takes up.

Detect change and exposure against a baseline

With comparable observations in hand, measure change rather than re-describe a single date, using the routes the Change Detection concept frames. Index or band differencing against a prior date flags vegetation growth into a right-of-way or new bare ground from construction and erosion; classifying each date and taking the difference names the transition where you need the category; and radar change or interferometric coherence loss flags structural or surface movement optical imagery cannot see. Exposure is the second half of this workflow and is a spatial overlay rather than a temporal one: intersect the corridor with a current hazard footprint — a flood extent or a burn-severity map produced by the sibling workflows — to report which segments now sit inside a hazard. Both kinds of result are anchored to the asset geometry and to a baseline, so the output is new encroachment or newly exposed segments since the last review, not a static inventory.

Separate true alerts from confounders, then validate

Infrastructure monitoring lives or dies on its false-alarm rate, because an inspector will abandon a queue that cries wolf. Before believing any flag, rule out the ordinary explanations: normal seasonal green-up read as encroachment, cloud or shadow the mask missed, temporary equipment or materials staged in a corridor during works, view-angle and illumination differences between dates, and — most commonly — poor asset geometry putting the buffer over the wrong ground. The habit is the one the other workflows use: treat each flag as a hypothesis, require it to persist across more than one pass before it escalates, and check it against the confounders first. Then validate the survivors explicitly — against higher-resolution reference imagery for the two dates, against a sample checked by eye, or against maintenance and inspection records — and express accuracy honestly, the same discipline the Classification Basics concept applies to any labelled output. Because true changes along a corridor are rare relative to its length, report the change class’s own reliability, not just an overall figure that a mostly-unchanged corridor makes look flattering.

Produce a prioritized review queue and make it repeatable

The deliverables of a run are a set built for action: a review map of flagged segments, a priority table by asset, segment, owner, or inspection route, and a QA note stating which dates were thin, where the mask worked hardest, and which flags rest on weak asset geometry or few validation points. Rank by the action threshold you set at the start so the crew works the corridor in the order that matters. This multi-date reasoning is the Time Series concept applied to a fixed network: the value is in the trend and the persistence, not any single scene. Finally, record the run so the next cycle repeats it exactly: the asset layer and buffer, the cadence and comparison window, the exact dates and sensors, the masking and reflectance products, the change and exposure methods and thresholds, and the baseline. With those written down the corridor can be re-checked next cycle, audited by an inspector, or ported between platforms without quietly changing what it measures — which is the whole point of a concept-first workflow.