Coastal Surge Scaling: Rerouting Fleet Logic by Shoreline Fetch and Run-Up

A fleet zone that works in a sheltered harbor collapses during a nor'easter when fetch runs 200 miles unimpeded. The difference isn't storm intensity alone — it's the shoreline's exposure. Fetch length and run-up elevation define how surge energy translates into flooded roads, stranded vehicles, and shifted demand. For demand-responsive fleet logic, static zones based on FEMA flood maps or historical call volumes miss the dynamic: surge doesn't respect administrative boundaries. This guide walks through rerouting fleet logic using coastal geomorphology data — fetch and run-up — as live inputs into dispatch algorithms. We assume you already operate a dynamic fleet system and need to harden it against coastal surge variability, not build one from scratch.

Why Fetch and Run-Up Break Standard Fleet Zones

Fetch is the uninterrupted distance wind travels over water before reaching shore. A 10-mile fetch in a bay produces a different surge profile than a 100-mile fetch on an open coast. Run-up is the vertical height water reaches above still-water level, driven by wave energy and local slope. Together they determine which roads flood, at what tide stage, and for how long. Standard fleet zones — even dynamic ones — often rely on static flood risk categories (e.g., 100-year floodplain) that don't update hourly. When a storm with long fetch arrives, flooding extends beyond mapped zones, and dispatch logic that doesn't account for real-time fetch underestimates service area contraction. Conversely, in short-fetch environments, static zones may over-warn, unnecessarily pulling vehicles from still-accessible areas. The mismatch causes two failure modes: vehicles dispatched into inaccessible zones, or excessive repositioning that wastes drive time and fuel. For demand-responsive fleets, where every minute of availability matters, these errors compound rapidly.

The Mechanism: How Fetch Drives Surge Timing

Fetch length correlates with wave period and surge duration. Longer fetch allows larger waves and prolonged setup, meaning high water persists longer after wind subsides. Fleet logic that only checks instantaneous water levels misses the lag. A vehicle may enter a zone that appears dry at dispatch but becomes impassable 20 minutes later as surge continues to build. Incorporating fetch into a predictive model — even a simple one — shifts the decision window from reactive to proactive.

Run-Up and Access Point Vulnerability

Run-up depends on beach slope and nearshore bathymetry. Steep slopes concentrate wave energy, producing higher run-up but narrower inundation. Gentle slopes spread energy, flooding wider areas but with slower rise. Fleet rerouting must differentiate: a steep-slope access road may be blocked by a single wave event, while a gentle-slope area becomes a slow, deep flood that traps vehicles. Run-up data, combined with real-time wave forecasts, allows dispatch to flag specific road segments — not whole zones — as high-risk.

Prerequisites: Data Sources and System Readiness

Before rerouting logic, you need three data layers: shoreline fetch polygons, run-up elevation profiles, and real-time surge forecasts. Fetch polygons can be derived from NOAA's digital coastline and wind fetch models (e.g., the USGS FetchR tool or similar open-source scripts). Run-up profiles require beach slope data from lidar or local surveys; many coastal management agencies publish this at 1–10 meter resolution. Surge forecasts come from NOAA's ESTOFS or local wave models — the key is hourly updates at shoreline segment resolution, not basin-wide averages.

System Integration Requirements

Your fleet management platform must accept geo-fenced zones that update on a sub-hourly cadence. If your system only supports static polygons, you'll need an intermediary layer — a microservice that ingests surge forecasts, applies fetch-run-up logic, and outputs updated zone boundaries as GeoJSON. The microservice should run at least every 15 minutes during storm events. Latency tolerance: if your dispatch decisions take 5 minutes to propagate, the surge model must lead by 10–15 minutes to avoid sending vehicles into developing flood zones.

Team Competencies

You'll need at least one person comfortable with coastal processes (a marine geographer or coastal engineer) and a data engineer to wire the pipeline. If your team lacks coastal expertise, start with a simplified model: use fetch as a binary flag (long/short) and run-up as a threshold. Over-refinement without validation introduces false precision.

Core Workflow: Integrating Fetch and Run-Up into Dispatch

The workflow has five steps, each building on the previous. Step one: segment the shoreline into fetch exposure classes. Using a 1 km shoreline buffer, calculate fetch for each segment at 16 compass directions. Classify segments as sheltered (fetch < 10 km), moderate (10–50 km), or exposed (> 50 km). These classes determine baseline surge sensitivity. Step two: assign run-up elevations per segment from lidar-derived beach profiles. Combine with local tide datums to compute threshold water levels for road access — e.g., a road with crown elevation 2.5 m NAVD88 becomes impassable when run-up exceeds 2.0 m at high tide. Step three: ingest real-time surge forecasts and map them to segments. For each forecast timestep, compute whether surge + tide exceeds the road threshold. Step four: generate dynamic zone polygons. Instead of one large zone, create micro-zones of ~500 m shoreline length. Mark each as open, caution (monitor), or closed based on threshold exceedance. Step five: feed micro-zone status into your dispatch optimizer as hard constraints — vehicles cannot enter closed zones, and caution zones incur a penalty factor (e.g., 1.5x drive time).

Example: Open Coast vs. Estuary

On an open coast with 100 km fetch, a 1.5 m surge may close roads 2 hours before peak tide. In an estuary with 10 km fetch, the same surge height may leave roads passable because wave energy dissipates over mudflats. The workflow captures this: the fetch class triggers earlier closure for the open coast, while the estuary segment stays open longer. Without fetch differentiation, both would close at the same forecast height, unnecessarily reducing fleet coverage.

Parameter Tuning

Start conservative: close zones when surge + tide reaches 80% of road crown elevation. After one storm season, adjust based on observed flooding. Track false positives (zone closed but road passable) and false negatives (zone open but flooded). A 10% false positive rate is acceptable for safety; false negatives should be near zero. Use A/B testing: run the new logic on a subset of vehicles while keeping others on static zones, compare service completion rates and repositioning costs.

Tools and Environment Realities

Open-source tools dominate this space because coastal data is public. Fetch analysis: Python's xarray and shapely with a wind fetch library (e.g., fetchpy). Run-up modeling: the USGS run-up equation (Stockdon et al., 2006) implemented in a few dozen lines of Python. Surge forecasts: NOAA's ESTOFS NetCDF files, available via THREDDS server. For the dispatch integration layer, Node.js or Python microservices work well; the key is a lightweight GeoJSON output that your fleet platform can ingest. Cloud infrastructure: AWS Lambda or Google Cloud Functions can run the pipeline every 15 minutes at low cost ($10–50/month during storm season).

Hardware and Connectivity Constraints

If your fleet operates in areas with intermittent cellular coverage, the microservice must cache zone updates to vehicle tablets before connectivity drops. Pre-load a 6-hour window of zone status at shift start. During storms, push incremental updates via satellite messenger if available. Vehicles without real-time connectivity should fall back to a static exclusion zone — the outermost floodplain boundary — which is conservative but safe.

Commercial Alternatives

Platforms like ESRI's ArcGIS Coastal tools offer fetch and run-up analysis with GUI, but at higher licensing cost ($5,000+/year). For teams without Python expertise, this may be faster. However, the dispatch integration still requires custom development — no off-the-shelf fleet system natively ingests fetch-based zones. Budget for a 2–4 week integration sprint if outsourcing.

Variations for Different Coastal Constraints

Not all shorelines behave alike. Adapt the core workflow to three common settings: open coasts, estuaries, and protected bays. Open coasts (fetch > 50 km) need aggressive closure thresholds because surge builds fast and wave setup amplifies run-up. Use a 70% road crown threshold and update zones every 10 minutes during storm warnings. Estuaries (fetch 10–50 km) have longer lag between wind and surge due to channel friction; use a 90% threshold but a wider caution buffer (1 km inland) because flooding spreads laterally. Protected bays (fetch < 10 km) rarely see surge above 1 m, but local wind-driven waves can still block low-lying roads. Here, run-up is the dominant factor — close only segments with beach slopes < 1:10, where wave energy concentrates.

Mixed Shoreline Segments

Many operations span multiple fetch classes within a single service area. In that case, apply per-segment logic and let the dispatch optimizer handle transitions. A vehicle moving from a sheltered bay to an open coast segment should receive a zone status update before crossing the boundary. This requires a continuous geofence that re-evaluates at each segment edge — not a single polygon for the whole area.

Seasonal and Tidal Adjustments

Fetch is constant, but run-up varies with tide and season. During spring tides (higher high tides), reduce all thresholds by 0.3 m. During El Niño winters, when sea level is elevated, apply an additional 0.15 m offset. These adjustments are simple linear modifiers but significantly reduce false negatives. Track tide predictions from NOAA's CO-OPS stations within 50 km of your service area.

Pitfalls and Debugging: What to Check When It Fails

Even with good data, the logic can fail. The most common failure: zone closure lags behind actual flooding. Cause: surge forecast update frequency is too low (e.g., every 6 hours). Fix: switch to a nowcast model that updates hourly, or blend forecast with real-time water level from nearby gauges. Second: false positives — zones close but roads remain passable. Cause: run-up threshold too conservative or beach slope data outdated. Fix: verify lidar data age; beaches erode and accrete seasonally. If data is >5 years old, use a safety margin of 0.5 m or conduct rapid field surveys after winter storms. Third: dispatch optimizer ignores zone penalties because penalty weight is too low. Ensure the penalty factor for caution zones exceeds the cost of a potential stranding — typically 2x–3x normal drive time cost. Fourth: microservice crashes during peak load. Storm events trigger many zone updates simultaneously; if your microservice processes all segments in one thread, it may time out. Implement parallel processing by fetch class or geographic region.

Validation Drills

Before storm season, run a tabletop exercise: feed historical surge data from a past storm (e.g., Hurricane Sandy for Northeast US) through your pipeline and compare zone closures to actual road flooding reports. Measure precision and recall. Adjust thresholds until recall > 0.9 with precision > 0.7. Repeat for three different storm types (long-fetch, short-fetch, rain-dominated).

When Not to Use This Approach

This logic is overkill for fleets operating exclusively in inland areas or behind sea walls that eliminate surge risk. It also fails in areas with rapid bathymetric change (e.g., river mouths after dredging) where fetch and run-up models become inaccurate within weeks. In those cases, rely on real-time water level sensors instead of predictive models.

Frequently Asked Questions and Next Steps

Q: How do I get fetch data for a shoreline outside the US? A: Use the European Marine Observation and Data Network (EMODnet) coastline and wind data, or compute fetch manually from nautical charts using GIS. The Global Self-consistent Hierarchical High-resolution Shoreline (GSHHS) dataset is free and works worldwide. Q: Can I use this with a ride-hailing fleet, not just logistics? A: Yes, but passenger safety thresholds are stricter. Use a 50% road crown threshold and close zones 30 minutes earlier than for cargo. Q: What if my fleet platform doesn't support dynamic GeoJSON zones? A: Pre-compute static zones for each forecast scenario (e.g., low, moderate, high surge) and switch between them manually. It's less precise but better than nothing. Q: How often should I update the beach slope data? A: Annual updates for open coasts, every 2–3 years for sheltered areas. Major storms may require immediate re-survey.

Concrete Next Moves

1. Map your service area shoreline into fetch classes this week using free NOAA data. 2. Identify the top 10 road segments most vulnerable to run-up based on lidar slope. 3. Set up a test pipeline that ingests ESTOFS forecasts and outputs a single micro-zone status for one segment. 4. Run a historical storm replay to validate thresholds. 5. Expand to all segments after one successful drill. 6. Train dispatchers on the new zone status display and escalation protocol. 7. Schedule a post-season review to refine parameters.