Methodology

How the block brief is calculated

The brief is designed to be useful in about 10 seconds and transparent in under a minute. This page shows the exact logic behind each module, where fallback matching is used, and how severity labels are assigned.

Geometry First

v1 prioritizes point + radius for predictable, fast API queries.

Default radii: 150m (block-ish) and 400m (nearby).

Transparent Severity

Every module includes Low/Medium/High plus threshold copy and impact framing.

No hidden scoring model.

Resilient By Design

Dataset failures degrade a module, not the whole page.

Partial rendering + per-dataset caching.

Interactive Explorer

Use these controls to see how scoring, locality filtering, and data scope work behind the scenes.

Geometry Scope

Adjust radius to see how much area each query can cover.

Approx area: 0.50 km² (7.1x of 150m baseline)

Severity Simulator

Preview the impact sentence and severity chip logic for each module.

No active disruption signals.

Low severity. No immediate disruption signal. Typical travel and curb access conditions are likely right now.

Low: 0 active disruptions. Medium: 1-2. High: 3+.

Event Relevance Logic

Simulate how event rows are ranked to avoid borough-wide noise.

Score: 5 (High relevance)

Dataset Browser

Search datasets and filter by module to inspect source coverage quickly.

Scoring and ranking rules
  • 311 pulse ranks complaint types by count in the current 30-day window, then compares to prior 30 days.
  • Street works ranks active-now first, then longer duration, then proximity.
  • Collisions clusters records within 75m and labels hotspot by frequent intersection text.
  • Right now strip combines active closures, active street works, and active film permits.
  • Events are ranked for locality using community district, closure signal, and nearby street-text signal.
Reliability and caching model
  • Each module queries independently so one outage does not blank the full brief.
  • Per-block and per-dataset cache keys reduce latency and API load.
  • High-churn datasets refresh frequently while stable layers cache longer.
  • User-visible warnings appear when partial data is shown.
Known limitations and current fallbacks
  • Some datasets lack stable geometry and require BIN/BBL, borough, ZIP, or text-based matching.
  • Sanitation uses DSNY Frequencies (rv63-53db) while the preferred schedule source (p7k6-2pm8) remains sparse through this API path.
  • v1 uses radius consistency over full blockface precision for speed and reliability.

Back to search