Every storm, resolved to the grid cell.
GridRain fuses weather radar, rain-gauge networks and numerical weather models into one quality-controlled rainfall grid — the storm that just passed, the rain falling now, and the days ahead — delivered to the teams who manage water, and written out as InfoWorks ICM CSV and RED for the hydraulic models they run. Every cell can tell you how it got its number.
1 km grid · 15-minute forecast steps · 5-minute archive · minutes-to-days forecasting · InfoWorks ICM CSV and RED export
One rainfall grid for monitoring, modeling and forecasting.
Most teams stitch rainfall together from a handful of gauges and a raw radar loop. GridRain delivers a single, quality-controlled, gauge-corrected grid — historical archive, live conditions and forecast — in the formats your hydrologic and hydraulic models already expect.
High-resolution rainfall
Gauge-corrected radar rainfall on a 1 km grid at 15-minute steps — the spatial detail a gauge network alone can never capture.
Forecasts that stay current
Radar-based nowcasting blended into high-resolution weather models, so the near term and the days ahead come from one continuous grid.
Historical archive
Years of quality-controlled grids at 5-minute steps — finer than the forecast — for design storms, recurrence-interval analysis, model calibration and forensic reconstruction. Storms are catalogued as discrete events, so you retrieve one by date instead of hunting through a continuous series.
Model-ready delivery
A rainfall file for the hydraulic model you already run: InfoWorks ICM CSV in in/hr, InfoWorks RED in mm/hr, one profile per 1 km cell. Plus georeferenced raster for GIS and a REST API that returns the whole grid, a single cell, or every catchment in a boundary file.
Catchment intelligence
Rainfall aggregated to your basins, sewersheds and assets, with per-cell recurrence-interval and threshold context. A catchment too small to contain a grid-cell centre comes back empty rather than zero — because "too small to resolve" and "no rain fell" are different statements, and a hydraulic model must not read one as the other.
Always-on monitoring
Continuous ingestion and quality control. Depth and intensity are both evaluated against your thresholds on the forecast windows you configure, and which of the two crossed is recorded with the event. When one crosses, the alert reaches email, SMS or the incident channel your team already watches — and you can test-fire the route on a quiet Tuesday rather than discovering it at 3 a.m.
One gauge, one number
One reading, applied everywhere. The whole area is assumed to have received what the gauge caught.
A grid, one value per square kilometer
Peak actually observed over the core — about 4.7× the gauge reading, a few kilometers away from it.
This gap is the whole problem. Storm cells are frequently smaller than the spacing between gauges, so the wettest part of a system routinely falls between instruments. Sizing or defending infrastructure against the gauge number means sizing against the wrong storm. Figures illustrative.
Built for the people who manage water and risk.
Water & wastewater utilities
Wet-weather and overflow modeling, collection-system capacity, real-time control — and a monthly wet-weather package assembled for permit reporting rather than exported and reformatted by hand.
Counties & municipalities
Stormwater planning, drainage design, flood awareness and a defensible rainfall record for the public and for claims.
Flood control & water districts
Basin rainfall input for early warning, reservoir inflow forecasting and gate and operations decisions.
Engineering & consulting firms
Rainfall input for hydrologic and hydraulic modeling, master plans, and design-storm and recurrence analysis — written in the format the model reads, so a calibration study starts with the rainfall settled rather than argued.
Emergency management & DOTs
Live rainfall and near-term forecasts to position crews, close roads and act before water rises.
Dam safety & reservoirs
Watershed rainfall for inflow forecasting, spillway decisions and post-event documentation.
Why a kilometre matters.
Rainfall is not smooth. An intense summer cell can drop three inches on one neighbourhood and almost nothing two kilometres away. The grid you analyse on has to be finer than the storms you care about, or the storm gets averaged out of existence before you ever see it.
GridRain
1 km² · 1 km grid, 15-minute steps
Typical regional model
9 km² · ~3 km grid, hourly
Typical global model
169 km² · ~13 km grid, 3-hourly
A 13 km cell covers 169 times the ground a 1 km cell does. Whatever fell inside it arrives as a single number, so an intense cell and a drizzle over the same footprint can report identically. Resolution is not cosmetic — it decides whether an event is visible at all. Areas are exact; grid spacings are typical values for the model classes named, not any specific product.
| Property | GridRain | Gauge network alone |
|---|---|---|
| Spatial coverage | Every square kilometre | Only where a gauge stands |
| Between instruments | Estimated by radar, corrected to gauges | Unknown — interpolated at best |
| Peak capture | Resolves the core wherever it lands | Missed unless the core hits a gauge |
| Instrument failure | Screened, and recorded either way | Propagates into the record silently |
| Point accuracy | Anchored to the gauges it trusts | Excellent — at the gauge |
Gauges are the ground truth and GridRain does not replace them — it uses them. The difference is what happens in the space between.
| Property | GridRain | Raw radar mosaic |
|---|---|---|
| Magnitude | Corrected against ground measurements | Inferred — can sit high or low all storm |
| Distance from the radar | Accounted for; coverage quality recorded per cell | Present and unlabelled |
| No-coverage areas | Marked as unobserved | Commonly rendered as zero |
| Reprocessing | Archive recomputed as methods improve | What was captured is what you keep |
| Output form | Model-ready grids and basin series | Imagery |
Radar supplies the structure and the coverage. It does not, on its own, supply a defensible number.
| Property | GridRain | Coarse global model |
|---|---|---|
| Grid spacing | 1 km | ~13 km (≈169× the cell area) |
| Time step | 15 minutes | Typically 3 hours |
| Convective cells | Resolved individually | Averaged across the cell |
| Observed conditions | Included — radar and gauges | Forecast only |
| Useful range | Minutes to two days | Days to weeks |
Different tools for different questions. A global model is the right instrument for next week; it is the wrong one for whether a basin overflows tonight.
Every square kilometer of your system, colored by the rain that fell on it.
GridRain resolves rainfall across your whole service area, so you can see where the storm concentrated, which sub-basins crossed an action depth, and which assets sit under the heaviest accumulation. Brightness shows cumulative depth; ringed cells have crossed their alert threshold. Service area and storm below are illustrative.
This is a static preview — the live application streams your actual service-area grid.
Launch appPeak 24-hour depth — —
A single distant gauge might have caught a fraction of what fell over the storm core. The grid shows the whole field. Illustrative.
Grid cells above action depth — —
In the live application these roll up to your own catchments, which are flagged the moment they cross their action depth — without waiting for a downstream gauge to confirm it.
Assets under the core — —
Lift stations and plants sitting inside the heaviest accumulation surface first, so crews go where the water actually is.
A rainfall grid becomes operational the moment it is weighted to the catchments you actually run. Set an action depth, hover or tab through a basin, then switch the map from the 1 km grid to the basin average to see exactly what averaging costs you.
At or above 2.0″
Illustrative map of a service area divided into basins on a 1 km rainfall grid. The ranked list beside the map carries the same figures as text.
Hover a cell for its depth · Tab steps through basins wettest-first · Enter pins one · Esc clears
Select a basin to see its depth, its peak cell and the asset locations inside it.
Service area, basins, asset locations and storm are invented and illustrative.
Peak intensity and total depth answer different questions — one drives inlet and conveyance capacity, the other drives storage and overflow volume. A storm can be severe on one and unremarkable on the other, which is why both are kept at full time resolution rather than reduced to a daily total. Figures illustrative.
Play the storm back. Pin the cell you actually care about.
A rainfall grid is a time series, not a picture. Scrub through six hours of a slow-moving system in 15-minute steps, switch between storm total, per-step depth and instantaneous rate, and select any square kilometre inside the service area to see how far a single point departs from the average across the whole of it. The storm, the service area and the gauge positions below are synthetic and illustrative.
Cumulative depth is the storm total so far. The increment is what fell during this one step. The intensity is the rate at the instant the step ends. The map, the profile under the scrubber and the chart always show the same quantity — each on its own scale, both printed. Cells outside the dashed boundary are hatched and excluded from every average here; pinning a cell can rescale the chart’s vertical axis, but scrubbing never does.
Interactive rainfall grid. Hover a cell with the pointer, or use the arrow keys to move the cell cursor. Home and End jump to the first and last cell in the current row. Enter or Space pins the cell under the cursor and draws its own time series in the chart below. Escape clears the pin.
Across the whole service area this storm totals —. The wettest single kilometre totals — — and the three gauge symbols on the map, all inside that same service area, sit on cells that recorded —. That spread is not noise; it is what a 1 km, 15-minute record preserves and a point network or a coarse grid averages away. Storm, service area and gauge positions are synthetic; every figure here is illustrative and none is a measurement, a benchmark or a service level.
The rainfall your model runs on, written in the format it reads.
A hydraulic model is only as defensible as the rain you put into it. Most studies still run on one gauge stretched across a whole catchment, or on a grid too coarse to hold the storm — and when the model does not match the flow record, nobody in the room can say whether the model is wrong or the rainfall was. GridRain takes that argument out of the study. One value per square kilometre, every step, written out as an InfoWorks ICM CSV in inches per hour or an InfoWorks RED in millimetres per hour, one profile per grid cell, every timestamp in UTC.
Any storm in the archive, at 5-minute steps. Call the event up by date, check it on the map, and export the same field you were just looking at. The calibration event and the picture of the calibration event are the same object, so there is nothing to reconcile between them.
The same export off the live and forecast grid, at 15-minute steps. A run for the next two days draws its rainfall from the same place the operator's screen does, so an operations forecast and a planning study cannot quietly disagree about what fell.
One profile per 1 km cell, not one number for the catchment. Nothing is averaged before your model sees it. The spatial detail arrives intact and your subcatchments do the aggregating — on your geometry, not on ours.
What the file does not carry, it does not pretend to. A model-input file is exactly that: values, units and timestamps, and nothing else. The project, the window, the extent and the provenance live in the report exports beside it, where a reviewer will go looking for them.
| What the model needs | What the export carries | What you still do |
|---|---|---|
| Rainfall as an intensity, not a depth | in/hr in the CSV · mm/hr in the RED | Nothing |
| One profile per spatial unit | one column per 1 km cell in the CSV · one PROFILE per cell in the RED | Nothing |
| A fixed time step | 5-minute from the archive · 15-minute from live and forecast | Nothing |
| Values that start where the run starts | the first row is one step after the run start, then one row per step | Nothing |
| An unambiguous clock | every timestamp in UTC, stated on the export before you take the file | Run the model on UTC, or shift once on import |
| Cells tied to your catchments | each cell keyed by an id that runs in a fixed order over the project grid | Map the grid to your subcatchments once |
Six things a rainfall input has to get right, and where each one is settled. Four are settled inside the file; two need one decision from you, and the file is not coy about which. The units, the step and the clock are fixed by the export, so the two files cannot disagree with each other or with the grid the operator is looking at. The clock is the one to carry across in your head: both files are written in UTC throughout, and the export says so at the moment you take it. The cell-to-subcatchment mapping is yours to make once, because it belongs to your model's geometry and not to ours — and once made it holds for every storm you export afterwards. Layout illustrative; the export states the exact cell count, step count and interval for your project before you take the file.
Radar sees everywhere. Gauges measure truth. We fuse both.
Weather radar maps the structure of a storm in fine spatial detail, but it infers rainfall indirectly, and how far it drifts depends on distance, terrain and the kind of storm. A rain gauge measures accurately at one point — and tells you nothing about what fell between gauges, and nothing at all when it clogs or tips out of level. Correcting one against the other produces a grid more accurate than either source alone.
Radar rainfall input
A national dual-polarization radar mosaic, quality-screened at source and resampled onto your 1 km grid. Radar sees the whole storm; what it cannot do is measure it. GridRain’s work begins there — correcting that field against the ground, which is where the error that matters to you actually lives.
Gauge correction
The radar field is corrected against the gauges that reported — in real time, so you have a number while the storm is still running, and corrected again afterwards, when the full gauge record is in and the archive is worth more than the deadline was.
Automated quality control
Gauges are screened before they are trusted, and no reading is ever set aside quietly: the decision is recorded against that gauge, on that storm, with its reason, and you can look it up. Screening outcomes carry forward, so a gauge that has been unreliable for weeks does not arrive at the next storm treated as a fresh and credible source.
More than one correction method — and you can see all of them
There is no single correct way to correct radar against gauges, so GridRain does not quietly pick one on your behalf. It computes more than one over the same storm and puts them side by side on one colour scale. Where they agree, the number is robust to that choice and you can defend it. Where they disagree, you find out before you build on it — which is worth considerably more than one averaged number that conceals the disagreement.
Verification you can inspect
Forecasts and corrected fields are scored against measured rainfall over your own basins — bias, error and detection — so accuracy is a number you look up rather than a claim in a brochure. When a period had nothing to score against, the metric is marked unmeasured rather than left as a zero that reads like perfect skill.
Do not take our word for it. Read the record.
Accuracy is the claim in this industry that is always asserted and almost never checked. GridRain scores the products it publishes against rainfall that was actually measured, over a rolling window, and shows you the result whether or not it flatters us. Verification is part of the product, not part of the sales deck.
Typical error size, by week
Root-mean-square error against measured rainfall, in inches. Lower is better.
Skill against lead time
How much of a rainfall event a forecast still catches as the lead time grows — the same honesty the likely-range band shows, measured after the fact instead of predicted.
Skill falls with lead time in every rainfall forecast ever written, and the reported bands do not sit perfectly on the smooth curve drawn through them. Both of those are supposed to be visible. A curve that stayed flat, or bands that landed exactly on it, would be a drawing rather than a record. Figures illustrative.
Your record stays empty until your catchments are on the grid.
Everything above is a worked example with invented numbers. In your account the same scores are computed over your own catchments, against the rain-gauge networks covering them, over a rolling window — and recomputed on a schedule as new rainfall is measured, so the record ages with the product rather than being frozen at the moment you signed. Every score carries the count of observations behind it, and it exports with the period, extent and units stated in the header.
From the next fifteen minutes to the next two days.
Different decisions need different lead times — and they should not require different tools. GridRain runs a family of models across the whole range and blends them into one continuous grid, so the transition from radar-driven nowcast to model-driven forecast is continuous rather than a hand-off you have to reconcile.
Left of now the value is measured, so it carries no band. Right of it every value is a range — a central estimate inside a low–high band that widens as the lead time grows. The widening is the honest part. A two-day forecast drawn as confidently as a two-hour one is claiming a precision no model has. The storm here is invented: this figure shows how confidence decays with lead time, and it is not a specification of any product — which products state a numeric range, and how far ahead, varies.
This figure is drawn in the browser. The illustrative readings below carry the same values as text.
- 1Observed — already fallenmarker here
- 2Nowcast, 0–6 h — live responsemarker here
- 3Short-range, 6–24 h — same-day planningmarker here
- 4Extended, 24–48 h — next-day positioningmarker here
Plan against the range, not the middle of it.
Left of now there is no band, because the value was measured rather than predicted. Right of it, the band is the middle 80% of this figure's own illustrative distribution, and the percentage is read from that band and nothing else — the arithmetic is printed so you can check it instead of taking it on trust. Note that the low edge flattens rather than turning back down: a cumulative total cannot un-rain, so no part of the range may ever go backwards. All figures illustrative.
Issued 72 h out
0.22–1.98″central 0.98″Outcome outside range
Issued 48 h out
0.72–2.28″central 1.45″Outcome inside range
Issued 36 h out
1.02–2.42″central 1.66″Outcome inside range
Issued 24 h out
1.38–2.44″central 1.88″Outcome inside range
Issued 12 h out
1.78–2.30″central 2.01″Outcome inside range
Forecasts are not issued once. Five successive issuances of one storm on one shared scale: the range tightens as the event approaches and the central estimate walks toward what actually fell. The earliest issuance missed — the outcome landed just above its stated high edge. That is what an 80% range is supposed to do: be wrong about one time in five. A band that contains the outcome every single time is not more accurate, only too wide — which is why a stated range is only worth as much as its calibration. All figures illustrative.
Radar nowcast
The range where what is already on the ground beats anything a weather model can tell you, so this is the product that leans on observation rather than on prediction. It is what crew positioning and real-time control run on.
Blended short-term
Observation gives way to forecast without a seam. Neither is trusted past its useful range, and your time series carries no step change in the middle of it where one product stopped and the next began.
Extended outlook
Longer-range guidance for staffing, storage drawdown and pre-storm positioning — with the uncertainty stated rather than hidden.
Probabilistic, not just a single number
Short-range forecasting carries a low, a median and a high estimate rather than one line, so you can plan against a credible worst case and afterwards state exactly what you were planning against. Where a product is deterministic it is labelled deterministic, not dressed in a band it does not have.
Compare models side by side
Several forecast products on one screen — same map, same time step, same colour scale, same catchment. The spread between products is a confidence signal in its own right, and a single model shown alone can never give you one.
Now
Sharp and compact — observed, not predicted.
+6 h
Moved and broadening. Position still confident.
+24 h
Broader, weaker. Timing less certain.
+48 h
An area, not a core. Plan for a range.
Forecast fields genuinely smooth out with lead time — that spreading is information, not a rendering artefact. A two-day forecast drawn as sharply as a nowcast is claiming a precision no model has. All four panels share one colour scale, so the fade is real rather than a trick of rescaling. Figures illustrative.
“About two inches” is not an operational answer. “A one-in-three chance of crossing your 2″ action depth” is — it tells you whether to pre-position crews, and what you are risking if you do not. The curves flatten with lead time because confidence genuinely falls. Exceedance probabilities are computed on the short-range probabilistic forecast; the longer-lead curves are drawn here to show that flattening, not to offer a calibrated two-day probability. Figures illustrative.
A gap is reported as a gap — never as zero.
Rainfall data is used to size infrastructure, justify capital work and answer regulators. That only holds up if the record is honest about its own limits. GridRain is engineered so that missing information is visible rather than quietly filled in — the failure mode that makes a dataset dangerous is not being wrong, it is being confidently wrong.
Zero rainfall and no observation are stored as different states. A cell the radar could not see is never written as a dry cell, and never silently interpolated to one.
Radar coverage is recorded alongside the rainfall itself, so a 0.00 reading can be identified as measured-dry rather than never-observed.
Every stored interval carries where it came from — which source it was built from, when it was ingested and how many gauges contributed to the correction.
Exports state what is present and what is not. A report over a window with a data outage says so, rather than presenting a shorter record as though it were whole.
Analyses can be recomputed for a past period without re-acquiring the raw data, so when a method improves the whole archive can be brought forward onto it — rather than leaving you with a record built two different ways either side of an upgrade date.
The archive is stored at 5-minute steps, finer than the forecast. A short-duration peak is what sizes an inlet, and it disappears completely inside an hourly total.
Any single cell can be asked how it arrived at its number — the raw radar value, every gauge evaluated against it, and every gauge it declined to use, with the reason.
The three states are never collapsed into one another. An hour outside radar coverage is not a dry hour, and a gap is not a zero — so a total computed over this month is reported against the intervals that actually exist, with the shortfall stated. Figures illustrative.
How the same hour is written out
The same 16 cells (9% of the area) are declared missing rather than given a value — so every total computed from this grid states the area it actually covers.
Arrow keys move between cells; Home and End jump to the start and end of a row, and with Control to the first and last cell. Each cell announces its value, its data state and its coverage quality. Press Enter or Space to move to the audit trail for the selected cell, which sets out what the radar saw, which gauges were within influence and which were excluded and why, and the value that was finally written. All values are illustrative.
176 cells in the domain. Counts are exact; percentages are whole numbers chosen so they sum to 100. The map is GridRain's view of the hour in both modes — only the record changes.
Typical export
0.56inArea average reported over 100% of the area — because 16 cells that were never observed were each given 0.00.
GridRain
0.62inArea average over the 91% of the area actually observed, with the 9% shortfall stated alongside it.
0.62 in × 91% observed = 0.56 in — counting unobserved cells as dry understates the average it reports by exactly the fraction of the area it did not observe. That is arithmetic, not an estimate: it holds for every storm, every window and every basin, and it is invisible in the export that caused it.
6 of the 16 unobserved cells sit inside the storm, where the true depth ran 0.72 to 0.97 in — a substituted 0.00 there is a hole in a wet field, and a careful eye might catch it. The other 10 sit at the far edge of the domain, where the true rainfall ran from 0.00 to 0.36 in — there a 0.00 only makes a light cell lighter, at the edge of the map, which is the kind of thing nobody catches. Neither one is marked as substituted. The export carries a number either way, and nothing in it separates a measurement from a substitution. Across a multi-year archive nobody eyeballs each hour, so the shortfall simply lowers every total computed over the period. Storm, service area, gauges and all values illustrative — the coverage shown is a constructed example, not a service-level figure.
How much crossed your trigger — and how unusual was that?
A depth only means something against a duration: two inches in a day is a wet Tuesday, two inches in an hour is a response. Choose a duration window and a trigger depth — the map, the distribution, the affected area and the catchment roll-up recompute together, and the depth–duration curve shows where the event sits between ordinary and rare. Storm, service area and catchments below are illustrative.
Depth reached in any 1 hour, anywhere in a rolling 48-hour record.
Which cells crossed it
Every 1 km cell shaded by the deepest total resolved there in the selected window. Cells at or above the trigger are ringed.
How the whole service area is distributed
Cells binned by depth, with the trigger drawn as a movable line and the exceeding tail shaded. A single gauge reports one bar of this; the grid reports every bar — the whole distance between the peak and the area mean above.
Drag the marker, or click anywhere in the plot, to move the trigger. The slider above is the keyboard control for the same value.
Distribution of 375 one-kilometre grid cells by maximum depth in any 1 hour, in 14 equal bins. 0.00 to 0.17 inches: 105 cells. 0.17 to 0.34 inches: 65 cells. 0.34 to 0.51 inches: 60 cells. 0.51 to 0.69 inches: 64 cells. 0.69 to 0.86 inches: 33 cells. 0.86 to 1.03 inches: 18 cells. 1.03 to 1.20 inches: 9 cells. 1.20 to 1.37 inches: 8 cells. 1.37 to 1.54 inches: 4 cells. 1.54 to 1.71 inches: 2 cells. 1.71 to 1.89 inches: 2 cells. 1.89 to 2.06 inches: 3 cells. 2.06 to 2.23 inches: 2 cells. 2.23 to 2.40 inches: 0 cells. 106 of 375 cells are at or above the trigger of 0.60 inches in any 1 hour.
At a trigger of 0.60″ in any 1 hour, 28.3% of the service area — about 106 km² — crossed it. At the wettest 1 km cell the rolling 1-hour total stayed above the trigger across a span of 3 h 30 m, and that cell peaked at 2.15″, which sits between the illustrative ≈25-year and ≈100-year reference depths for this duration. 2 of 4 catchments had more than a quarter of their area in exceedance.
| Catchment | Area | Cells above | Share | |
|---|---|---|---|---|
| Northwest interceptor | 90 km² | 33 | 36.7% | |
| Northeast branch | 108 km² | 21 | 19.4% | |
| Southwest basin | 79 km² | 4 | 5.1% | |
| Southeast outfall | 98 km² | 48 | 49.0% |
Where the event sits against generic recurrence shapes
Deepest total anywhere in the service area, against duration on a logarithmic axis. The dotted curves behind it are generic illustrative shapes — not values from any published precipitation-frequency dataset, and not suitable for design use.
Illustrative depth-duration values. Maximum anywhere in the service area: 15m 1.12 inches; 30m 1.64 inches; 1h 2.15 inches; 2h 3.31 inches; 3h 3.72 inches; 6h 4.27 inches; 12h 5.02 inches; 24h 5.63 inches. Service-area average: 15m 0.17 inches; 30m 0.30 inches; 1h 0.47 inches; 2h 0.72 inches; 3h 0.87 inches; 6h 1.31 inches; 12h 1.92 inches; 24h 2.53 inches. The four reference curves behind them are generic illustrative shapes labelled approximately 2, 10, 25 and 100 years, and are not values from any published precipitation-frequency dataset.
Every number here is derived from one deterministic illustrative storm over an illustrative 375 km² service area — not a real event, location or customer — and the recurrence curves are generic shapes rather than a published dataset. What is real is the method: a threshold is only meaningful against a stated duration, and the honest answer to “did we exceed it” is an area and a span of time, not a single number. Notice that this event is rarest between about half an hour and six hours, and steps down a whole reference band when read as a 24-hour total — a distinction a daily rainfall figure cannot make, and the reason sub-hourly resolution is worth having. In the live platform the same question is asked of your own catchments against the gauge-corrected grid, with the exceedance, the duration and the verification all inspectable.
Build the storm once. Defend it for years.
Most design storms end up as a depth in a spreadsheet, with the reasoning long gone. Storm Studio keeps the reasoning attached. Every storm you build is saved under a name, listed beside the others you tried, and carries what you asked for and how the depth was reached into the export itself, where a reviewer can read it without asking you. The depths below are invented and illustrative.
| Return period | Depth | Where the number comes from |
|---|---|---|
| 2 yr | 2.85″ | Published |
| 5 yr | 3.60″ | Published |
| 10 yr | 4.25″ | Published |
| 15 yr | 4.71″ | Interpolated |
| 25 yr | 5.30″ | Published |
| 50 yr | 6.15″ | Published |
| 100 yr | 7.10″ | Published |
A frequency table has columns, not a continuum — and the return period a reviewer hands you rarely lands on one. Ask for 15 years here and a depth does come back: 4.71″, pinned between the two published columns that straddle it (4.25″ and 5.30″), and carrying a mark that says the table never printed it. How the number is read between those two columns is our own modelling choice, and it is disclosed as one rather than dressed up as a published method. Ask for a return period past the table’s last published column and there is no depth to give at all, because a plausible number invented past the end of a table is worse than nothing — it looks like evidence. Depths, durations and return periods are invented. Figures illustrative.
A saved storm is an object, not a session. Name it, add a note, and it takes its place in a list beside every other storm you tried — each one showing how long it ran, what it averaged, what it peaked at and the day it was saved, with the settings that produced it kept underneath. Rename one, drop one, set two against each other. Come back a year later from a different desk and the whole study is still standing.
And every one of them says whether it still holds. A saved storm records what it was built from, and states on its face whether rebuilding it today would land in the same place. Where that cannot be established it says exactly that — not known is never quietly promoted to yes.
What leaves carries its own account of itself. Alongside the rainfall goes a written record of the build: what was asked for, what the depth was read from, and whether that figure was a column the table published or one worked out between two that were — plus a SHA-256 digest per file, so a bundle re-zipped with one member swapped cannot pass for the original; where a digest cannot exist, the row is still there carrying the reason, because an absent row reads as a missing file. Anything the build could not supply is left empty rather than filled in with something plausible, and anything derived rather than measured is stamped as derived, so the two can never be read as the same thing.
The storm you design against is a decision, not a download.
Every design storm carries assumptions — where its shape came from, how long it runs, how deep it goes, where it sits on the ground, whether it moves. Those assumptions get made either way. The only question is whether you made them, or something made them for you. The storm below is invented and illustrative.
Moves the storm’s heaviest fifteen minutes through the six hours. The total depth, the duration and the peak intensity do not change.
This figure is drawn in the browser. The readings below carry the same illustrative values as text.
An illustrative six-hour design storm, in fifteen-minute steps. Upper panel: the rate in each step, rising to a peak of 1.20 inches per hour and falling away. Lower panel: the depth accumulated from the start, against the straight line a storm raining at one steady rate for the whole six hours would draw, with the two ends of the control drawn faintly as dotted curves. At the setting shown, the heaviest fifteen minutes begins 2 hours 15 minutes into the storm; the storm’s centre of mass is at 2 hours 48 minutes; a quarter of the depth has fallen by 1 hour 51 minutes and three quarters by 3 hours 42 minutes. At its widest the storm is 0.53 inches ahead of a uniform storm, 4 hours 15 minutes in. The storm total, 3.75 inches, the duration, 6 hours, and the peak intensity, 1.20 inches per hour, are identical at every one of the twenty positions the control can take.
Fixed by the specification
Not fixed by the specification — this is the choice
Every position of the control produces a storm with the same total — 3.75″ — over the same 6 h 00 m, reaching the same 1.20″/hr. Those three are exactly equal at all 20 positions, not approximately: the curve always finishes in the same corner and the bars always touch the same ceiling. A depth and a duration fix the first two; the third is held fixed here on purpose, so that the only thing left moving is where the water sits. Push the heaviest fifteen minutes on by 15 minutes and the storm’s balance point moves 5 minutes — exactly one third as far, because the tails redistribute around it. At the setting drawn the storm runs 0.33″ behind a uniform storm of the same total and duration at +1:15, crosses it during its own heaviest fifteen minutes, and is 0.53″ ahead by +4:15; the middle half of its depth falls between +1:51 and +3:42. Two storms can satisfy the same depth and duration to the letter and not be the same design case. Adopting a published temporal distribution answers that question; it does not make it go away — which distribution, and which of its variants, is still a decision someone makes, and unlike the shape drawn here it will generally move the peak rate too, which widens the gap between two compliant storms rather than narrowing it. The shape here is the simplest that can hold all three numbers exactly fixed while the loading moves; it is not a standard distribution and not product output. Storm, depths and durations are invented. Figures illustrative.
Rain that fell, or a standard shape
Build on a storm your own ground actually recorded, or on a published design shape. It is the same builder and the same finished product either way: build a recorded event and a design case to the same duration and the same time step and they can be read together afterwards, cell for cell. Build them differently and you are told which property differs, rather than being shown a comparison that quietly is not one.
Depth from the published curves, or from you
Read the design depth off the published depth-duration-frequency table for your own area, at the duration and return period you are working to. Or state it yourself, when a reviewer has already fixed the number and the job is to build the storm that matches it. Where that target is read from a published table it is a POINT depth applied as a basin mean, which for anything larger than a point runs high, and increasingly so with area — so the basis is stated on the build itself, and an areal reduction factor is applied only if you ask for one, recorded as a factor you supplied or as a generic default, never as a number GridRain vouches for.
Set the duration — and decide what gives
A recorded storm rarely runs exactly as long as the duration you have to design for. Say explicitly what gives when it does not, rather than letting something quietly rescale the intensities on your behalf. The recorded storm and the one you asked for are on screen together before you commit to either.
Every shape says how far it can be traced
A design shape may come straight from the body that issues it, be derived from that, arrive second-hand, or be one you supplied. Each is labelled with which, so a reviewer can see the difference at a glance. Shapes not held are listed as absent with the reason, rather than left off the list.
Move it off where it actually fell
Take a storm that clipped one corner of your area, re-centre it over the ground you actually care about, and set it moving on a bearing and speed you choose. What comes back is how much of it lands inside your area step by step, and what each of your boundaries would have caught.
Check it, then hand it to the model
Set the finished storm against the published depth-duration-frequency table for your own ground, at every duration you tested, before you commit it. Then take it away in the forms a hydraulic model already reads — per-cell and per-boundary time series, the cell footprints as GIS geometry, and a rain-gage input file.
Two storms look alike until you put them on the same scale.
Storm summaries usually arrive one at a time, each drawn to its own axis. Read that way a moderate event and a severe one land on the page as much the same shape, and the difference only surfaces if someone remembers to check the numbers underneath. Read several storms together instead — one clock, one depth scale, one map view, whether they came out of your archive or were built to a design standard — and what you are looking at differs because the storms differ, not because the charts do. The three storms below are invented and illustrative.
Switches the upper row only. The storms are identical either way — the axis is the only thing that moves.
Three illustrative storms drawn as rainfall-intensity profiles over a twelve-hour window, in fifteen-minute steps. Upper row: one panel per storm, all three on one scale running 0 to 2.40 inches per hour. Lower row: the same three profiles overlaid on one axis. Storm A delivers 2.49 inches, peaking at 2.36 inches per hour 2 hours 45 minutes into the window, with 2 hours 30 minutes of measurable rain. Storm B delivers 3.77 inches, peaking at 0.42 inches per hour 5 hours 15 minutes into the window, with 11 hours 30 minutes of measurable rain. Storm C delivers 3.16 inches, peaking at 1.20 inches per hour 7 hours 30 minutes into the window, with 6 hours 30 minutes of measurable rain in 2 separate spells. Storm B delivers the largest total and Storm A the highest peak.
| Storm | Storm total | Peak intensity | Peak arrives | Wet time |
|---|---|---|---|---|
| Storm A short and intense | 2.49″ | 2.36″/hr | +2:45 | 2 h 30 m |
| Storm B long and steady | 3.77″ | 0.42″/hr | +5:15 | 11 h 30 m |
| Storm C two peaks | 3.16″ | 1.20″/hr | +7:30 | 6 h 30 m |
Storm B carries the largest total of the three — 3.77″ against storm A's 2.49″ — and the lowest peak intensity. Storm A is the opposite case: the shortest, and by a wide margin the sharpest. Total depth and peak intensity size different things, so neither one on its own says which storm is the harder case for a system. Put each on an axis fitted to itself and all three panels fill out much the same way; put them on one axis and the intensity ranking is immediate — the depth ranking is not, and is very nearly the reverse, which is what the table below is for. Times run from the start of the shared window; wet time counts steps with measurable rain and need not be continuous — storm C rains in two separate spells. Storms, depths and durations are invented. Figures illustrative.
One square kilometre, every storm
Point at any cell inside your service area and read what each compared storm delivered there — total depth, its own peak rate, when that peak arrived, how long it rained. A ranking that holds across the whole area can reverse over a single catchment, which is usually the catchment you were asked about.
How much of the area got wet
An inch on average is a uniform inch everywhere, or four inches over a quarter of the ground, and the two size very different infrastructure. Compared storms are binned on one shared range, so you read the spread rather than the average that hides it.
Nothing quietly dropped
Storms that cannot be set against each other — different ground, different span — are refused before anything is drawn, naming which storm and which property differs. One that simply fails to load keeps its place with the reason stated. Either way you get an answer you can question. A silently shortened line-up is not something you can question, because you never learn it was shortened.
Set a threshold. See what crosses it.
Every control on the left drives the view on the right. Change the action depth and the flagged cells, the affected area and the asset count all recompute — which is exactly how the decision gets made in the live platform. Storm, service area and assets below are illustrative.
Rainfall across the service area
Every 1 km cell coloured by accumulated depth. Cells above the action depth are ringed.
How the storm arrived
Depth accumulating at the wettest cell, against the action depth you set on the left.
How much of the system got how much rain
Cells binned by depth. A single gauge reports one bar of this distribution — and rarely the tallest one.
Scored against what actually fell
Forecast products are compared to measured rainfall over your own basins — how reliably rain was detected when it fell, how far the totals ran high or low, and how both decay with lead time. A window with nothing to score against is marked unmeasured, so a zero cannot be read as perfect skill. Structure shown; figures illustrative.
| Lead time | Detection | Bias | Skill (0–1) |
|---|---|---|---|
| 0–6 h | 0.88 | +4% | 0.74 |
| 6–24 h | 0.71 | −4% | 0.55 |
| 24–48 h | 0.58 | −9% | 0.41 |
Skill falls with lead time in every rainfall forecast ever written. A vendor whose scorecard does not show that is not showing you a scorecard.
Output that lands in the tools and documents you already use.
Rainfall data has to leave the platform to be useful — into a hydraulic model, a capital-planning memo, a GIS workspace or a regulatory submission. The model-input files carry values, units and UTC timestamps and nothing else, because that is what a model reads. Every report export opens with a header naming the project, the products it was built from, the data sources behind those products, the time window in your project's timezone, the spatial extent, and the moment it was generated in UTC alongside your own zone. Values carry their units. A year later the file can still be read correctly, and challenged correctly.
For the modelers
Rainfall written as model input rather than as a table you reformat: InfoWorks ICM CSV in in/hr, InfoWorks RED in mm/hr, one profile per 1 km cell, at 5-minute steps from the archive or 15-minute from live and forecast, every timestamp in UTC. It comes off the same grid the operator is looking at, so your model input and their screen cannot quietly disagree — and the API returns per-catchment totals on your own boundary file, masked the same way the alerting masks it, so an integrator never reimplements point-in-polygon and gets a different answer.
For the report writers
Presentation-quality documents with embedded maps and charts, consistent branding and a metadata block that makes the analysis reproducible — including an NPDES wet-weather monthly package that lists every storm event, cross-checks each one against the rain gauges that reported, and appends the data lineage and quality-control counts a permit reader will ask for.
For the GIS team
Georeferenced gridded output that drops straight into a spatial workspace, carrying its own projection and an explicit no-data value (NaN), written into the file as a tag — so an unobserved cell arrives in your GIS as no-data rather than as a very convincing zero that survives every downstream join.
Frequently asked
How is this different from a free radar map?
What resolution and update frequency do I get?
Where does the data come from?
How do you handle gaps and outages?
Can it feed my existing models?
Do I have to map grid cells to my subcatchments?
Can it alert my team?
Do you keep a historical archive?
See your watershed on the grid.
Tell us your region and the models you run, and we will set up a demo grid over your basins for a recent storm. Already a customer? Go straight to the live application.