What pivot geometry is, and why every sector report starts there

If you've spent any time around pivots, you already know the shape: a long arm swinging around a fixed point, towers rolling on wheel tracks, an end gun throwing extra water past the last span. Pivot geometry is just the formal name for that shape, mapped out as data instead of memory. Center point, radius, span lengths, tower positions, end gun throw, any wrapped or part-circle sectors where the machine doesn't run a full 360. Put it together and you've got a model of exactly where water is supposed to land, at what rate, at every point along the sweep.
That part isn't complicated. A field engineer who's walked a specific circuit for a season can usually sketch that pivot's geometry from memory. Nobody's checking every pivot against it every week, though, and that's the gap a sector report is built to close.
Why geometry is the baseline, not the finding
A sector report only means something if it's being compared to the right shape. If you flag a dry patch on a pivot without first knowing that pivot's actual radius and span count, you can't tell if that's a bad sector or just the edge of the circuit where coverage normally thins out. Geometry is what turns a patch of stressed crop into a specific, nameable sector, something you can point to and say "span 3, second quarter, outer third" instead of "somewhere out past the county road."
This matters more than it sounds like on paper. Two pivots with the same brand of sprinkler package can have completely different geometries once you account for a corner that's been clipped for a field boundary, an end gun that only fires on part of the sweep, or a span that was shortened after a tower got stuck in a wet spot two seasons back. None of that shows up unless the geometry is built from how the machine actually runs today, not how it ran when it was installed.
What this looks like against index and thermal passes
Once the geometry is set, a pass of multispectral and thermal imagery gets laid over it, sector by sector, instead of over the field as a flat square. That's the difference between "this field looks stressed in the northeast corner" and "sectors 4 through 6 on the outer span are reading dry, and sector 9 near the end gun is reading wet." The first tells you something's off. The second tells you what to go look at, and whether it smells like a clogged nozzle, a leak dragging down pressure on one arm, or a stuck end gun throwing water where it isn't needed.
Over-irrigation shows up the same way, just flipped. A sector that's consistently wetter than its neighbors, in a part of the circuit where geometry says it should be getting the same application rate as everything else, usually points to a nozzle package problem or a leak. Without the geometry as the baseline, that pattern just reads as normal field variability and gets written off.
Why this beats driving the circuit
The whole reason to build a sector report this way is that eyeballing a circuit from the truck catches the obvious stuff, the sector that's already brown, the end gun that's visibly throwing a rooster tail where it shouldn't. It misses the early stuff, the sector that's trending dry but hasn't shown it in the canopy yet, the slow leak that's been bleeding pressure for three weeks before anyone notices a wet spot from the road. A weekly check against each pivot's own geometry catches that earlier, because it's comparing where water should be against where it is, sector by sector, every pass.
That's the whole idea behind Irrigation Monitor, a per-pivot sector report built from each machine's real geometry so you can see which sectors are drifting before you've driven out to confirm it. If you're tired of catching nozzle problems a week after they started, that's worth a look.