Urban Planning Validation Platform

Background

Taipei's disaster response decision-making has long been constrained by a "data gap": the 1,470 narrow alleys registered in urban planning records and the 274 entries in the fire department's field survey have never been cross-referenced.

The fire department currently publishes two related inventories, last updated in May and October 2024 respectively—neither on a regular annual cycle. The only existing visualization is a citizen-made Google My Maps from 2014, with data frozen since 2016. For a decade, the city has lacked any tool to answer: where are the narrow alleys, how high is the risk, and does the planning reflect reality?

· Market Pain Point: Existing tools cannot quantify the gap between planning records and fire department practice, leaving disaster resource allocation without a precise basis.
· Core Thesis: Urban planning geodata should not be a static document—it should be a verifiable spatial hypothesis.
· Technical Goal: Validate the feasibility of a Laravel + PostGIS architecture in Taiwan's public-sector GIS environment, and test the integration viability of migrating from Google Maps commercial APIs to an open-source map infrastructure based on GeoServer.

Challenges

1. Data Reality and the Cascading Problem of Missing Geometry
   The original plan was to compare planned road widths against field-measured widths. However, Taipei's publicly available field measurement data only covers segments wider than 8 meters and is in Polygon format—field-measured line segments for narrow alleys simply do not exist in public channels. The fire department's 274 entries include field-measured widths, but only as Chinese-language addresses with no coordinates or line geometry. Without source geometry, spatial comparison of length, density, and positional reliability cannot be established.
2. Semantic Gap in Spatial Definitions Across Regulatory Domains
   Urban planning uses the building code threshold of <3.5m; the fire department's red-zone threshold based on rescue operations is <4m. The two systems have fundamentally different definitions of "narrow alley"—the system had to present this discrepancy without forcing a unified value.
3. Boundary Definition and Trade-offs in Independent Research
   Without a specification document, I had to independently prioritize features across technical depth, social value, and development cost. Any imbalance risked drifting the system away from its core purpose as a decision-support tool.

Actions

1. Spatial Reconstruction Strategy
   To address missing geometry in the inventory, I built a proxy mechanism of "borrowing existing geometry and annotating credibility boundaries." The automated snapping pipeline runs only once at data import: Geocoding to point → TWD97 projection → ST_ClosestPoint snapping to planned road segments—ensuring the live system does not depend on external services.
2. Coexistence Rendering Strategy
   Rather than forcing the two conflicting logics into one, I rendered both planned and field-measured values on the same segment using dual-layer drawing. Risk classification strictly follows the Ministry of Interior's statutory 3.5m threshold; the fire department's red/yellow zone classification is displayed as-is without reinterpretation—methodological transparency is itself the credibility of this system.
3. Layered Architecture Constraint
   Business logic (risk calculation, discrepancy judgment) is fully encapsulated in the backend (Laravel + PostGIS); the frontend (React 19 + TypeScript + OpenLayers 10) handles only rendering and interaction.

Execution

1. Case A｜Data Transformation: From Heterogeneous Addresses to Spatial Risk
   Facing 274 fire department entries with only text descriptions, I had to reconstruct spatial relationships without source geometry. Despite complete inventory structure, the address semantics were highly heterogeneous.
   
   1. Technical Breakthrough
   Validated Google Geocoding's ability to parse ambiguous semantics, and implemented an automated pipeline: Geocoding → TWD97 Projection → ST_ClosestPoint Spatial Snapping.
   2. Making Uncertainty Explicit
   Rather than filtering out uncertain data, the system explicitly annotates "distance offset" and "width offset" warnings in popups (e.g., ❗ High Offset), turning technical limitations into credibility boundaries that decision-makers can evaluate.
   3. Data Discovery and Output
   By deduplicating via matched_road_id, successfully identified 202 risk segments that the fire department had field-surveyed but urban planning had never registered—completing Taipei's first integrated narrow-alley spatial profile.

2. Case B｜Decision-Oriented Dashboard and Risk Classification
   The initial system used a composite "narrow alleys × fire hydrant density" model with dynamic circles, producing three problems: the hydrant threshold lacked statistical basis, the composite metric was unintuitive, and map visual noise was too high.
   
   1. Model Simplification and Noise Reduction
   Decisively distilled the metric to a single "narrow alley density (count/km²)." This eliminated derivation errors and ensured the target audience could identify high-risk areas at a glance.
   2. Statistical Anchoring
   Abandoned subjective thresholds in favor of quartile analysis computed from real data across Taipei's 12 districts (Q1: 2 / Q2: 7 / Q3: 20) as risk thresholds. This gave the extreme-risk classifications of Datong District (43.4) and Zhongzheng District (40.6) rigorous statistical grounding rather than visual intuition.
   3. Scenario-Driven Information Architecture
   Abandoned a separate dashboard page and integrated statistics into the left-side panel of the map. For planning meeting scenarios, this ensures "map distribution + statistical context" are simultaneously visible, avoiding cognitive interruption from cross-page navigation.

Outcomes

• Data Contribution: Identified 202 risk segments field-surveyed by the fire department but never registered in urban planning, building Taipei's first integrated narrow-alley spatial dataset (1,672 entries | 9.18 km).
• Technical Validation: Confirmed the feasibility of a full-stack Laravel + PostGIS + OpenLayers architecture in a public-sector environment, and proved that a self-hosted GeoServer + OSM basemap service can fully replace commercial APIs, achieving technical sovereignty.
• Methodology: Established a transferable risk assessment process that derives quantitative thresholds from regulatory text combined with quartile-based statistical anchoring.

  Data Category	Count	Total Length (km)	Decision Value
  Urban Plan Alleys (plan only)	1,398	6.21	Statutory risk zones pending field verification
  Fire Dept. Field-Surveyed New Entries (field only)	202	2.97	Reveals real gaps not yet reflected in planning data
  Dual-Confirmed (high-risk overlap)	72	0.31	Priority hotspots for budget allocation
  Total	1,672	9.18	Complete spatial profile of narrow alleys across Taipei

Reflections

• The Ultimate Practice of Role Integration
  This was the first project where I connected PM problem definition, UX sensibility, Technical Architect design, and full-stack Engineering—all with the same pair of hands. Role integration was not always smooth: early on I wrote business logic (risk judgment) in the frontend, until I realized that scattering judgment logic across the visual layer made the system unmaintainable. This process taught me that architectural layering is not just a technical convention—it's the means of ensuring product goals and implementation stay aligned over time.
• The Semantic Turn in Data Governance
  I realized that data integration is not a technical problem but a semantic and governance problem. The right architectural decision is not to eliminate uncertainty, but through architectural honesty—using warning mechanisms to surface data credibility boundaries—to ensure the system maintains transparent and reliable decision value even when data is imperfect.
• Establishing Professional Identity
  Across these three projects combined, I clarified my positioning: not an engineer accumulating depth in a single vertical domain, but someone who can independently build systems in highly uncertain environments, bringing problem definition, architectural design, and full-stack implementation together. This is not an expansion of roles—it's the first time these three capabilities have been integrated into a single working state.