UNREACHABLE：如果緊急車輛知道地址，卻無法抵達建築物，會怎樣？

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Imagine calling an ambulance or the fire service during an emergency. You provide the address. The location is correct. The route looks reasonable on a map.

But there is a problem: the vehicle reaches the neighbourhood, yet cannot physically reach the building.

A narrow lane, illegally parked vehicles, construction material, a blocked entrance, or insufficient turning space can turn the final stretch of a journey into a serious obstacle. Knowing where an emergency is happening does not necessarily mean knowing how to reach it.

That is the problem I am exploring with UNREACHABLE — an AI-powered emergency accessibility intelligence platform.

The idea began with a simple question:

What if emergency navigation could tell us not only where a building is, but also whether an emergency vehicle can plausibly reach it?

UNREACHABLE is designed to connect street-level accessibility evidence with road-network analysis. Instead of treating every mapped road as automatically usable, it aims to help identify potential access constraints, understand which buildings may be affected, and prioritize improvements that could make a real difference.

The platform is built around five connected capabilities:

• Access Atlas: A map-based view of buildings, roads, emergency facilities, and potential bottlenecks. It brings accessibility information into one place instead of leaving it scattered across separate observations.
• AI Access Inspector: An AI-assisted way to examine street photographs and identify potential obstructions, such as parked vehicles or construction material. These are observations that can be reviewed by a human—not automatic declarations that a road is unsafe or impassable.
• Vehicle-Aware Route Analysis: An approach to assessing road-network reachability against a selected emergency vehicle's constraints, using available road data and explicitly defined rules.
• Bottleneck Impact Simulation: A way to explore a hypothetical question: if a constrained road segment were cleared or improved, which additional buildings might become reachable through the network?
• Fix-First Prioritization: A way to help identify which constraints deserve investigation first, based on factors such as affected buildings, severity, alternative access, and the freshness of the evidence.

These capabilities are intended to work together. The goal is not simply to mark a road as blocked. It is to connect a possible obstruction to the buildings that depend on that road and make the potential consequences easier to understand.

The people who could benefit include emergency planners, municipal authorities, urban planners, and communities working to improve local emergency access.

UNREACHABLE is intended to complement existing maps and emergency-response systems, not replace dispatchers, emergency personnel, or on-site verification.

Code

GitHub repository: https://github.com/shiriei/UNREACHABLE

The project is being developed as a modular application, with the frontend, backend, sample geospatial data, and technical documentation separated so the components can evolve independently.

The goal is to make the reasoning behind an accessibility assessment understandable and inspectable, rather than hiding every decision behind an AI-generated result.

I also want the project to be useful as a foundation for future contributors: additional neighbourhood datasets, better vehicle profiles, improved obstruction verification, and more reliable road-network information should be possible to add without rebuilding the entire application.

How I Built It

I approached UNREACHABLE as a combination of geospatial analysis, conventional software engineering, and AI-assisted visual inspection.

The important design decision was to give each technology a specific job instead of asking AI to make every decision.

1. The application layer

The planned application architecture uses:

• React, TypeScript, and Vite for the frontend.
• FastAPI and Python for backend services.
• GeoJSON for representing sample buildings and road-network features.
• Geospatial and graph-analysis tools, such as Shapely and NetworkX, for geometry checks and road-network reachability where the available data supports them.
• OpenAI vision capabilities for identifying potential access-related observations in uploaded street photographs.

The architecture is modular because the interface, geospatial logic, and AI analysis have different responsibilities and should be testable independently.

2. Why AI belongs in this project

AI is useful here because photographs can contain visual clues that are difficult to capture through a simple list of road attributes.

A street image might show a parked vehicle occupying part of a lane, construction material near an entrance, or a passage that appears particularly constrained. A vision model can help turn those visual clues into structured observations that a person can review.

For example, an observation could record:

• The potential obstruction detected.
• The visible evidence supporting that observation.
• The location associated with the photograph, when provided.
• The observation time, when available.
• A verification status indicating whether a person has reviewed it.

This makes visual evidence easier to organize and connect to the map.

However, a photograph alone cannot reliably establish the exact width of a road, the current condition of an entire route, or whether a particular emergency vehicle can pass. Perspective, occlusion, image quality, and changing street conditions all matter.

That is why the intended workflow is AI observation → human verification → accessibility assessment, rather than AI prediction → unquestioned decision.

3. Why conventional algorithms still matter

A vision model can identify a possible obstruction, but it should not be responsible for inventing a route.

Road-network analysis handles a different question: given the road connections, known constraints, selected vehicle profile, and available evidence, which buildings have a feasible path under the system's rules?

A graph represents road segments and their connections. Constraints can be associated with individual segments. Reachability can then be recalculated when a segment is treated as constrained or hypothetically restored.

The impact of a proposed improvement can be expressed as:

Impact of a constraint = buildings reachable after the hypothetical improvement − buildings reachable before it.

This is an estimate produced under stated assumptions, not a measurement of real-world outcomes.

The analysis must also account for missing information. If road width, vehicle requirements, access restrictions, or network connections are unknown, the system should report Unknown where appropriate instead of silently assuming that access is possible.

4. Making the result actionable

A map full of warning markers is not enough.

UNREACHABLE is designed to help answer three practical questions:

1. What is the potential access problem?
2. Which buildings might depend on the affected road segment?
3. What could change if that constraint were investigated and resolved?

The prioritization layer can help organize these questions using transparent criteria, rather than presenting an unexplained AI-generated ranking.

The broader ambition is to move from seeing a problem to understanding its potential network impact.

Why Does Open Innovation Matter?

Emergency accessibility is a local problem with local details.

A road constraint in one neighbourhood may be caused by informal parking. Somewhere else, it may involve construction, a gated entrance, a sharp turn, or an incomplete road map. A solution that works with one dataset or one city's assumptions may not work everywhere.

That makes openness especially valuable.

First, the evidence can be challenged. Accessibility assessments should not be unquestionable outputs from a black box. Developers and domain experts should be able to inspect the underlying road data, assumptions, and reasons behind a result.

Second, communities can contribute local knowledge. Residents and local authorities may know about recurring obstructions or access restrictions that are missing from map data. A future version could incorporate structured reports with timestamps, location information, verification, and expiry rules so outdated reports do not remain authoritative indefinitely.

Third, the approach can be adapted. Different emergency vehicles and neighbourhoods have different requirements. An open, modular system makes it easier to introduce new vehicle profiles, datasets, and validation rules.

Fourth, independent contributors can improve individual parts. One contributor could work on geospatial reachability, another on visual-observation review, and another on accessibility-data quality, without requiring everyone to understand the entire codebase.

Open innovation does not automatically make a system accurate, and an open-source model is not automatically better than a closed one. The value here is the opportunity to make the overall approach more transparent, adaptable, and open to scrutiny.

For a project involving emergency access, that scrutiny is essential.

My Agent Session

[Optional: Add your DevRelay agent session link or embed your session here if you recorded one.]

During development, I have been breaking the project into manageable phases rather than attempting to build a complete emergency-response platform in one step. This helps keep the architecture understandable, makes individual features easier to validate, and reduces the risk of presenting unfinished functionality as a working capability.

The Lazy Payoff

The kind of work I want UNREACHABLE to reduce is the repetitive effort involved in piecing together accessibility information from separate maps, street observations, and road records.

Imagine a planner investigating a constrained road. Without a connected analysis workflow, they may need to inspect the road, identify the buildings beyond it, compare possible approaches, and manually reason about what might happen if the road were cleared.

UNREACHABLE aims to bring those steps into one workflow:

Identify a potential bottleneck → inspect the evidence → assess affected buildings → simulate an improvement → prioritize further investigation.

That does not eliminate the need for field inspections or professional judgment. It helps people spend less time connecting disconnected pieces of information and more time investigating the constraints that matter.

I am not claiming a measured time saving yet. Establishing that would require testing the workflow with real users and comparing it with their existing process. For now, the payoff is the opportunity to make an otherwise complicated analysis more visible, repeatable, and easier to discuss.

What Makes UNREACHABLE Different?

Road mapping, routing, computer vision, and geographic analysis already exist individually. I do not claim to have invented those technologies.

The innovation I am pursuing is their combination around a specific question: can the selected emergency vehicle plausibly reach this building, based on the evidence currently available?

Three ideas define that direction:

• Building-level consequences: Move beyond marking a road constraint to understanding which buildings may be affected by it.
• Evidence-connected AI: Use visual AI to produce reviewable observations, not unsupported declarations of passability.
• Explicit uncertainty: Distinguish verified access, constrained access, likely inaccessibility, and unknown access instead of treating missing data as proof of safety.

Together, these ideas aim to make emergency accessibility more understandable and more actionable.

Challenges and Lessons Learned

One of the biggest challenges is that a map is not the same thing as reality.

A road can appear connected in a dataset but be too narrow for a particular vehicle. A photograph can reveal a possible obstruction without showing the entire passage. A route that works for a car may not work for a fire tender. And an obstruction reported yesterday may have disappeared today.

These are not minor edge cases; they shape the system's design.

I have therefore treated data quality, human verification, vehicle-specific constraints, and explicit uncertainty as core requirements rather than features to add at the end.

Another challenge is scope. A citywide system with live reports, reliable vehicle specifications, verified road measurements, and operational emergency-service integration would require substantial data collection, validation, and partnerships. A hackathon prototype cannot honestly claim to have solved all of that.

The practical approach is to start with a clearly labelled sample neighbourhood, demonstrate the analysis end to end, make the assumptions visible, and build toward validation with real data.

What's Next?

The next steps are to strengthen the end-to-end workflow:

• Improve the quality and provenance of road and building data.
• Make the vehicle constraints and reachability rules explicit.
• Connect AI observations to a review and verification workflow.
• Test bottleneck simulations against carefully constructed scenarios.
• Evaluate the interface with people who understand emergency access and urban planning.
• Explore a small real-world pilot only when suitable data and expert validation are available.

The long-term vision is a tool that helps communities and planners identify potential emergency-access barriers before those barriers become critical during a real incident.

Prize Categories

Best use of GEMMA

UNREACHABLE starts with a simple principle:

Knowing where an emergency is happening is only part of the problem. We also need to understand whether help can physically get there.

The aim is not to let AI make emergency decisions. It is to help people see potential access barriers, understand their consequences, and investigate possible improvements with better evidence.

Because a destination on a map should never be confused with a guarantee of access.