Cloud cover gaps in a monthly vegetation index anomaly: interpolate or skip?

Every analyst who has pulled a monthly composite for a drought region has hit the same wall: a third of the polygon is under cloud, the rest is shadow-streaked, and the trigger date on the contract doesn't move just because the sky didn't cooperate. The index still has to get computed. The question is what you do with the pixels that are lying to you.

What a cloud-contaminated pixel actually does to your number

A cloud-contaminated pixel isn't just "missing data." Thin cirrus, haze, and cloud shadow all shift the reflectance values that go into the vegetation index math, usually in the direction of lower apparent greenness even where the crop or rangeland underneath is fine. Mix a handful of those into a regional average and the anomaly reads drier than the ground actually is. For a parametric trigger, that's not a rounding error. It can push a region into a payout band it shouldn't be in, or mask a real decline because the cloud-free pixels happen to sit over the healthier part of the polygon.

Most pipelines flag this at the pixel level with a quality mask, cloud, cloud shadow, snow, and clear, before the aggregation step runs. The part that matters for drought work is what happens next: do you fill the flagged pixels, or do you drop the month.

Interpolation vs. skip-month, and when each one is wrong

Interpolation fills a contaminated pixel from somewhere else: the same pixel in the prior clean month, the same pixel in the same calendar month from the historical record, or a weighted read from clean neighboring pixels. It keeps the time series continuous, which matters if your trigger logic depends on consecutive-month counts or a rolling average. The failure mode is specific: if the contamination lines up with the actual onset of drought stress, a temporal fill from the prior month will smooth over the exact signal you're trying to price. You end up interpolating your way past the thing the index exists to catch.

Skip-month means you don't manufacture a reading for the region that month. You carry the last confirmed value forward, flag the severity classification as unconfirmed rather than computed, and let the next clean pass settle it. This is the more honest option when contamination is heavy, say a large share of the region's pixels flagged rather than a scattered few, because an interpolated number built mostly from fill has stopped being a measurement and started being a guess dressed up as one.

The practical rule most teams settle on: set a contamination threshold for the region ahead of time, not after seeing how the month's imagery looks. Light, scattered contamination under the threshold gets filled, spatially where there's enough clean signal nearby, temporally where there isn't. Above the threshold, the month gets skipped and marked as such in the output rather than silently filled. Whatever rule you pick, apply it the same way across every region in the book. A trigger framework that interpolates generously in one region and skips in another, depending on which analyst was on shift, isn't a framework. It's a coin flip with extra steps.

Keeping the baseline consistent through the gaps

The other piece people miss: the historical baseline a monthly reading gets compared against has to be built with the same cloud-handling rule, not a cleaner version of the methodology applied retroactively. If the current month's reading survived a fill step but the twenty-year baseline for that pixel was built from cloud-free scenes only, you're not comparing the same thing. An anomaly is only honest when both sides of the comparison were cleaned the same way, since the number otherwise tracks methodology drift as much as it tracks actual vegetation condition.

None of this is solved by picking a smarter interpolation algorithm. It's solved by writing the rule down before the clouds show up, documenting which months were flagged, and refreshing the comparison the same way region to region, month to month. That consistency is the whole value of a monthly anomaly feed built against a fixed baseline, since the moment the methodology shifts between regions or between months, the output stops being something you can price against.

If you'd rather not build and maintain that rule set in-house, Drought Monitoring runs the monthly anomaly and severity classification against a multi-decade baseline region by region, so the cloud-handling decisions are made once and applied the same way every month.