Emergency Accessibility Scenario Planning

Purpose

Emergency Accessibility Scenario Planning computes rapid-response dispatch routes from emergency facilities (fire, police, ambulance) under multiple scenarios (blocked roads, facility unavailability, cascading demand), enabling contingency planning and resilience assessment.

Typical Questions This Tool Helps Answer

Under each disruption scenario, which populations and facilities fall outside our response-time targets?
Which scenario produces the worst accessibility loss and by how much versus baseline?
Which closure or blockage assumptions should be prioritized for mitigation planning?

Background

Network planning workflows use graph-theoretic representations of roads, routes, or linear assets, where node-edge topology and impedance attribution directly control results. Missing restrictions, incorrect turn logic, or stale demand assumptions can dominate outcome quality.

These tools are best interpreted as constrained optimization and diagnostics frameworks. Decisions should be based on trade-offs across service, resilience, and cost objectives rather than any single metric.

Emergency routing simulation stress-tests accessibility under disruptions, closures, and demand spikes. Value comes from comparing resilience trade-offs across scenarios rather than relying on single-run outputs.

Methodological Considerations

Topology validation should precede optimization or scenario simulation.
Explicitly represent operational constraints (time windows, restrictions, capacities, closures) before comparing objective outcomes.
Test outcomes under stress scenarios so selected plans remain stable under realistic disruptions.

Practical Interpretation Pitfalls

Single-metric improvements can hide degraded resilience or equity; compare candidate plans across multiple KPIs and scenario conditions.

Inputs

Parameter	Type	Required	Description
network	Vector (line)	Yes	Input network (`LineString` or `MultiLineString`).
critical_facilities	Vector (point)	Yes	Emergency origin facilities (`Point` or `MultiPoint`).
demand_points	Vector (point)	No	Optional demand points for KPI coverage calculations. Current KPI extraction uses `Point` geometries.
ring_costs	JSON array	Yes	Ring costs, for example `[5.0, 10.0, 15.0]`; each value must be finite and `> 0`.
scenario_csv	CSV	Yes	Scenario table with columns `scenario_id,max_cost_multiplier` and optional `blocked_value`.

Parameters

scenario_template (optional): custom, flood, wildfire, earthquake.
scenario_block_source_field (optional): network field used with blocked_value to block scenario edges.
baseline_service_areas (required): baseline output polygons path.
worst_case_service_areas (required): worst-scenario output polygons path.
scenario_summary_csv (required): scenario KPI output CSV path.
simulation_report (required): summary JSON output path.
html_report (optional): optional HTML report path.

Optional Routing Cost Parameters

Parameter	Type	Default	Description
edge_cost_field	String	—	Numeric line field used as impedance. If omitted, Euclidean arc length is used.
mode_field	String	—	Field identifying transport mode per edge.
default_mode_speed	Number	—	Default speed (km/h) for mode-speed conversion.
mode_speed_overrides	String	—	Comma-separated `mode:speed` overrides, e.g. `walk:5,drive:40`.
allowed_modes	String	—	Comma-separated list of permitted modes.
one_way_field	String	—	Field encoding one-way restrictions; accepts FT/TF/B codes and legacy boolean values.
node_cost_points	Vector (point)	—	Optional point layer containing node/intersection entry-cost observations.
node_cost_field	String	—	Numeric field in `node_cost_points` containing non-negative node entry costs.
node_cost_snap_distance	Number	—	Optional max assignment distance from each node-cost point to the nearest network node.
turn_penalty	Number	—	Cost added for each standard turn.
u_turn_penalty	Number	—	Additional cost for U-turns.
forbid_u_turns	Boolean	—	If `true`, U-turns are forbidden at all nodes.
forbid_left_turns	Boolean	—	If `true`, all left turns are forbidden.
forbid_right_turns	Boolean	—	If `true`, all right turns are forbidden.
turn_restrictions_csv	CSV	—	Per-turn transition table with columns `prev_x,prev_y,node_x,node_y,next_x,next_y`; optional `forbidden` and `turn_cost`.
temporal_cost_profile	CSV	—	Time-of-day speed profile CSV for scheduled routing.
temporal_edge_id_field	String	—	Network edge ID field that matches profile keys.
departure_time	String	—	ISO-8601 departure time, e.g. `"2024-06-15T08:00:00Z"`.
temporal_mode	String	—	One of `multiplier` or `absolute`.
temporal_fallback	String	—	Fallback when no profile entry matches: `static_cost` or `error`.

Scenario CSV Rules

Required columns:

scenario_id
max_cost_multiplier

Optional column:

blocked_value

Notes:

Quoted commas are supported.
max_cost_multiplier must be finite and > 0.
Blank rows are ignored.

Template checks:

flood: requires block-source field and at least one blocked_value; all multipliers must be <= 1.2.
wildfire: each multiplier must be in [0.5, 1.0].
earthquake: requires block-source field and at least one blocked_value.

Outputs

Output	Type	Description
baseline_service_areas	Vector (polygon)	Baseline merged service-area polygons.
worst_case_service_areas	Vector (polygon)	Service areas for the lowest-coverage scenario.
scenario_summary_csv	CSV	Scenario metrics and deltas from baseline coverage.
simulation_report	JSON	Baseline, scenario list, best and worst scenario summary.
html_report	HTML (optional)	Optional HTML wrapper over summary JSON.

Runtime output keys (returned in ToolRunResult.outputs):

Key	Points to
`baseline_service_areas`	Baseline service-area polygon file
`worst_case_service_areas`	Worst-scenario polygon file
`scenario_summary_csv`	Scenario KPI CSV
`simulation_report`	Simulation report JSON
`summary`	Alias → same path as `simulation_report`
`html_report`	Optional HTML report (only present when `html_report` argument is supplied)

`scenario_summary_csv` schema

scenario_id,max_cost_multiplier,blocked_value,covered_count,total_count,covered_pct,delta_from_baseline_pct

`simulation_report` schema

Top-level keys:

workflow
scenario_template
baseline
scenario_count
best_scenario
worst_scenario
scenarios

Example

import whitebox_workflows as wbw

env = wbw.WbEnvironment()
env.emergency_scenario_routing_and_accessibility_simulator(
        network="city_network.gpkg",
        critical_facilities="critical_facilities.gpkg",
        demand_points="demand_points.gpkg",
        ring_costs=[5.0, 10.0, 15.0],
        scenario_csv="scenarios.csv",
        scenario_template="flood",
        scenario_block_source_field="STATUS",
        baseline_service_areas="outputs/em_baseline.gpkg",
        worst_case_service_areas="outputs/em_worst.gpkg",
        scenario_summary_csv="outputs/em_scenarios.csv",
        simulation_report="outputs/em_report.json",
        html_report="outputs/em_report.html"
)

The example below adds travel-time impedance, turn penalties, and a peak-hour speed profile to make scenario comparisons more realistic.

env.emergency_scenario_routing_and_accessibility_simulator(
        network="city_network.gpkg",
        critical_facilities="critical_facilities.gpkg",
        demand_points="demand_points.gpkg",
        ring_costs=[5.0, 10.0, 15.0],
        scenario_csv="scenarios.csv",
        scenario_template="flood",
        scenario_block_source_field="STATUS",
        edge_cost_field="MINUTES",
        one_way_field="ONEWAY",
        node_cost_points="intersection_delay_points.shp",
        node_cost_field="DELAY_MIN",
        node_cost_snap_distance=25.0,
        turn_penalty=0.3,
        u_turn_penalty=2.0,
        forbid_u_turns=True,
        temporal_cost_profile="am_peak_profiles.csv",
        temporal_edge_id_field="EDGE_ID",
        departure_time="2024-06-15T08:00:00Z",
        temporal_mode="multiplier",
        temporal_fallback="static_cost",
        baseline_service_areas="outputs/em_baseline_peak.gpkg",
        worst_case_service_areas="outputs/em_worst_peak.gpkg",
        scenario_summary_csv="outputs/em_scenarios_peak.csv",
        simulation_report="outputs/em_report_peak.json",
        html_report="outputs/em_report_peak.html"
)

References

FEMA (Federal Emergency Management Agency) Hazard Mitigation Planning Guidelines

Parameter Interaction Notes

Results are most sensitive to scenario multipliers and demand-point completeness.

Larger ring costs and multipliers tend to increase measured coverage.
Missing or sparse demand points can make scenario comparisons look unrealistically favorable.

QA and Acceptance Criteria

Use a staged acceptance approach for Emergency Accessibility Scenario Planning:

Validate geometry types and scenario CSV schema.
Confirm required output paths are writable.
Verify scenario summary rows match parsed scenarios.
Confirm worst-case output corresponds to lowest covered_pct.

Recommended acceptance checks:

simulation_report.scenario_count matches expected scenario count.
delta_from_baseline_pct values match scenario vs baseline coverage math.
Worst scenario in JSON is reflected in worst_case_service_areas output.

Advanced Operational Guidance

For production deployment of Emergency Accessibility Scenario Planning:

Version control scenario CSVs and template choices for auditability.
Keep block-source coding dictionaries standardized across departments.
Validate scenario assumptions before interpreting policy decisions.

Implementation Patterns

Common implementation patterns with Emergency Accessibility Scenario Planning:

Baseline + full scenario batch run.
Targeted stress scenarios for known bottlenecks.
Governance run with archived CSV/JSON artifacts.

Use Emergency Accessibility Scenario Planning together with upstream conditioning and downstream validation tools in the same bundle to ensure end-to-end consistency and stronger decision confidence.

When To Use This Workflow

Emergency Accessibility Scenario Planning is most valuable when teams need measurable service-level improvements (coverage, response time, cost-to-serve) with governance-ready transparency.

What this workflow helps you achieve:

Translates network complexity into decision-ready options.
Supports defensible operational planning with explicit constraints.
Creates repeatable workflows for quarterly and annual optimization cycles.

Results Delivery Checklist

Before sharing results with stakeholders:

Validate network topology and impedance attributes for all served areas.
Confirm objective function matches business KPI priorities.
Document constraints (capacity, time windows, exclusions) in deliverable notes.
Provide baseline-vs-optimized comparison metrics.
Include at least one scenario stress test (demand spike, outage, or route closure).

Common Questions

Q: Why do all scenarios look similar to baseline?
A: Multipliers may be too mild or blocked values may not match network attribute values.

Q: Why is coverage always 100%?
A: If demand points are omitted, KPI coverage defaults to 100%.

Q: What does blocked_value control?
A: It selects which network edges are blocked in a scenario when mapped through scenario_block_source_field.

Whitebox Workflows Pro Customer Technical Reference