The conditions on an application used to be three dropdowns somebody completed from memory, usually days later. They are now filled in for you, from the farm's location and the times the work was actually done.
Because the value arrives on its own, it is worth knowing where it comes from — and what the small note next to it is telling you.
Weather belongs to a block, not to an application
Each block on an application carries its own start and end time, and its weather is looked up for exactly that stretch. An application that ran over three days because of rain gets the conditions of each of those days, on the blocks that were sprayed on them. There is no single set of conditions averaged across the whole job.
This is the part that makes the record worth having at an audit: the question is what the conditions were when that block was sprayed.
What the three values mean
The lookup returns an hourly series for the hours the block was being sprayed. The three values you see are a summary of those hours, and each is summarised differently:
- General conditions — the worst condition in the window, not the most common one. A shower in the middle of an otherwise clear afternoon is the thing that mattered to the job, so it is the thing that is recorded.
- Wind — the band the strongest gust falls in. Drift is caused by the gusts, not by the average.
- Temperature — the average across the window.
A block sprayed between 13:02 and 13:19 is summarised from the hour surrounding it rather than dropped for being too short.
The five states a block's weather can be in
| On screen | What it means |
|---|---|
| Weather pending | Nothing yet. The fill runs once the block's start time has passed. |
| A value marked forecast | The forecast for that window. Usable, and not final. |
| A value with no note | Confirmed against the measured record. This is the end state. |
| A value marked user-set | Somebody entered it. It will not be touched again. |
| Weather unavailable | Nothing can be fetched. See below. |
A forecast becomes a record
For a spray in the last few days, the only thing that exists is a forecast, so that is what is saved — marked as one.
About five days later the measured reanalysis for that date is published, and the same value is looked up again and replaced. The note disappears, and what is left is what the weather actually was.
So a value can change once, and only once, and only in that direction. Two things follow: a document printed in the first few days may carry a forecast, which is why it says so on the page; and a figure you disagreed with last week may be worth looking at again.
What you enter yourself is never overwritten
If you were there, you know better than any model does. Enter the conditions and they are marked user-set, and the automatic fill skips that block from then on — including the confirmation step that would otherwise replace a forecast.
Nothing about the automation takes that away from you. The bulk Set weather action starts on Blocks without weather yet, so it cannot overwrite anything you have already recorded. Choosing All blocks is how you overwrite, and you have to choose it.
When it says unavailable
Two reasons, with different fixes:
- The farm has no location. Nothing can be looked up without coordinates. Get in touch and we will set them.
- The spray is too old. The measured archive covers the last few months. An application from before that, with nothing captured at the time, cannot be filled in after the fact.
In both cases the conditions can still be entered by hand, and doing so is better than leaving the record empty.
Nothing is fetched while you wait
The weather service sits outside the app rather than inside a page load, so choosing Fetch automatically schedules the lookup instead of performing it. The value appears shortly afterwards; it will not be there the instant the modal closes.
That is also what keeps a slow or unreachable weather service from making the application pages slow.
Where the data comes from
The forecasts and the measured record both come from Open-Meteo, whose archive is built on the ERA5 reanalysis. Every page and document that shows a value sourced from it credits it.