It is raining somewhere on your way. The question is whether to leave now.

This exists because of one monsoon morning. The office needed reaching, the sky was doing something, and there was no way to find out whether the rain was on the route or three neighbourhoods away. Radar maps show you where water is falling. That is not the question a person standing next to a scooter is asking.

The real question has three answers, not two: go now, wait about half an hour, or do not go at all. It is a decision about time, and almost every weather tool answers a question about place.

That constraint drove everything else. The verdict is the largest thing on screen, the recommendation to wait is second, and every detail behind them is one tap away rather than in your face.

Today this answers for rain. The pipeline underneath does not care which scalar it is reading, and air quality, fog and heat index are built with real thresholds, waiting to be wired to the interface. Monsoon is four months; the same instrument should be useful in the other eight.

One test decides what belongs here: can it be measured independently and graded against ground truth, the way rain is graded against airport observations. Rain, air quality, visibility and heat all pass. Which route people prefer, or which neighbourhood is nicest, do not. Those are opinions, and an instrument that starts reporting opinions stops being one.

Weather on the Way, Drive Weather, Windy's route planner: they are competent, and they all answer "what will I drive through over the next four hours". That is a different question from "will I get soaked on a twenty minute commute, and is 18:40 better than now".

The second question belongs to people on two wheels, and there are an enormous number of them: India, Indonesia, Vietnam, Thailand, Italy, Taiwan. On a scooter the rain is not context, it is the entire decision. Nothing free, open and worldwide was answering it.

The gap is real, though partly because consumer weather is a poor business rather than because it is hard. Two paid iOS apps and an aviation site is what "genuinely useful, hard to monetise" looks like. Which is a reason to make it open, not a reason to skip it.

A route is not a point, and it is not a line either. It is a sequence of places you will be at specific future minutes. So the sampling is done in time, one point every five minutes of travel, rather than in distance.

Sampling by time means the number of lookups scales with how long the trip takes, not how far it goes, so a three hundred kilometre drive does not explode into hundreds of API calls. Deduplication matters more than it sounds: weather grids are one to twenty five kilometres wide, and in city traffic several consecutive samples land in the same cell.

Every provider returns a whole time series for each point rather than a single reading. That is the detail that makes comparing five departure times free: one fetch, five evaluations, no extra requests.

No single provider is trustworthy everywhere. Radar coverage is excellent across the United States, Europe and Japan, and patchy to absent across much of India, Africa and South East Asia. So the tool asks several and shows you the disagreement rather than averaging it into a confident looking middle.

Providers that publish a probability contribute it directly. The ECMWF ensemble runs the same model fifty one times from slightly different starting conditions, so its probability is a genuine count of members, not a heuristic. Providers that publish only an intensity contribute a hard yes or no, which is a real opinion, just a maximally confident one.

One number on that panel is deliberately unflattering:

Eight endpoints answered, but six of them are one operator serving different physics. Counting those as separate votes would inflate apparent agreement, which is exactly the failure this tool exists to avoid. Two forecasts agreeing means something. Two skins of one model agreeing means nothing, so the interface reports both numbers.

A national service that does not cover your continent is reported as out of area, never as a failure. Flagging a German provider as broken on every route outside Germany would make the failure warning meaningless inside a day.

This is the part no map app does. Five departure times are scored from the same fetched data: now, and fifteen, thirty, forty five and sixty minutes out. Each shows how many minutes of rain you would ride through if you left then.

When a later departure is meaningfully drier, the interface says so in a sentence, in the one place the amber accent is allowed: Wait to 18:45: dry the whole way. That single line is the product. Everything else is evidence for it.

The headline distinguishes cases that look identical in a single number. "Wet 31 of 46 min" and "Wet the whole way, 31 min" are very different situations: one says most of the ride is fine, the other says rerouting is pointless and only waiting can help.

Up to three alternatives are drawn, labelled with the road names people actually use, and ranked two ways at once. A map app can tell you which is fastest. This one also tells you which keeps you driest, and how many minutes the drier one costs.

The vehicle matters too, and not only for the roads. It changes the speed, which changes which forecast hour each point is checked against, and it changes what the answer means. On a scooter, cycle or on foot the rain lands on you. In a car it does not, so the same forecast reads "Rain for 31 of 46 min" and the thing that matters becomes visibility and standing water.

Forecasting rain thirty minutes out is genuinely hard, and a tool that hides that is worse than useless the first time it is wrong.

Worse, the difficulty is backwards from what matters. Light drizzle is the most predictable thing in the sky. Heavy convective bursts, the ones that actually ruin a commute, are the least. So the interface always shows which tier of data it is standing on: a radar nowcast and an interpolated hourly model are not the same thing and do not get to look the same.

Three rules the interface will not break:

Nobody publishes how well any weather provider actually performs anywhere. There is no peer reviewed skill curve for Indian monsoon nowcasting. Rather than assert accuracy, the tool measures itself and publishes the result.

Every hour, each provider is asked what it expects at twenty two reference airports for fifteen, thirty and sixty minutes ahead. Once that time has passed, the prediction is checked against the nearest METAR observation and scored.

One subtlety decides whether any of this means anything: a prediction only becomes eligible once its target time has actually passed. Scoring a fresh forecast against a fresh observation measures persistence, not skill, and would flatter every provider.

A metric is hidden unless it has both enough matched predictions and enough observed rain events. The first real run made that necessary: every observation that hour was dry, which arithmetically gives a false alarm rate of 100% to anyone who forecast rain at all. That looks like a damning verdict and is really an absence of weather.

There is no database. The prediction log and the scores accumulate as files in the repository, so the whole scorecard is free, public, and auditable in the commit history. See the scorecard.

The core runs with no API keys at all. Three independent forecast providers, a router, geocoding and map tiles, none of which need an account. Optional keys unlock live traffic, a genuine radar nowcast, and physical rain gauges across Indian cities, but nothing requires them and nothing ever will.

Adding a provider is the main way to contribute: implement one interface, register it, and nothing else changes. A contribution that would make a key mandatory is the one thing that will be turned down.