Planned2026

NJ Hazard Vulnerability Dashboard

One parcel core, 3 hazard scenarios, and a vulnerability score you can take apart.

Not built yet. Specified in a committed build guide alongside its sibling project; implementation has not started. The scoring framework below is a design, not a measurement.

  • flood
  • gis
  • climate
  • planning
  • data-pipeline
  • 3Hazard scenario families in scopescope, not a result
  • 4Drill-down levels, state to parcelscope, not a result
  • E·S·CExposure, sensitivity, consequence frameworkscope, not a result

Figures marked scope describe the size of the problem this project is specified to handle. They are not measurements — nothing has been run yet.

What this is

The planning-facing twin of the parcel flood risk dashboard. Same parcel backbone, different question: instead of a single-hazard finance lens, this screens every parcel against current flood, future flood and sea-level rise, and storm surge, and scores vulnerability with a transparent framework —

V = 0.45·E + 0.30·S + 0.25·C

exposure, sensitivity, and consequence-context, each visible in the parcel profile so a planner can see why a score landed where it did.

Shared parcel core consumed from the sibling project, never rebuilt 10 core sync checksum-verified against upstream Social context CDC SVI + NJ Overburdened Communities Scenario pipeline parcel × scenario grain 20 hazards current flood, future/SLR, storm surge 30 fact county-checkpointed; coverage honesty flags 40 scores V = 0.45·E + 0.30·S + 0.25·C 50 summaries · 90 validate Static dashboard no geoprocessing in the UI State → county → municipality → parcel scenario selector switches every view
What does it take to score one parcel against several hazard scenarios at once?NJ MOD-IV Hazard Vulnerability build guide §6 (stage names verbatim).

Why build both

Running the two projects on one parcel core is the point: the same data backbone powering two genuinely different decision products, one for underwriting and one for mitigation prioritisation. The second project consumes the first’s artifacts under a documented contract rather than reimplementing parcel ingest — a third implementation of the same ETL would be the failure mode, not a milestone.

Two commitments constrain the design. Every output is labeled screening for prioritisation, never a determination. And “not screened” — a parcel outside a scenario’s data footprint — is carried as its own state, distinct from “not exposed”, because collapsing the two would quietly turn missing data into good news.

Weights are locked at the framework’s starting values with a mandatory calibration check before publication: if well-documented high-risk municipalities do not rank in the top quartile under flood scenarios, the discrepancy gets written up rather than the weights getting nudged.

Share this page

https://abdulkalam.pages.dev/projects/nj-hazard-vulnerability/

Scan to open this page. Download the SVG for print.