Overlapping Accessibility: The Fire Station Example

Background

Where should a fire station be located?

At first glance, this sounds like a relatively simple spatial planning question. Put a station where it can reach as many people as possible, preferably within a certain amount of time.

In practice, it is considerably more complicated.

The location of a fire station is not just a question of geometric distance. What matters is how long it takes an emergency vehicle to actually reach a location through the road network. One-way streets, road classes, speed limits, intersections, traffic signals, bridges, gradients, surface conditions, the structure of the built environment and the traffic volume can all influence travel time.

And the question is ultimately not simply where is a station? It is:

Which parts of the population can be reached within the required time, and how does this change if a station is moved, added or removed?

This makes accessibility analysis a central component of fire protection planning.

In North Rhine-Westphalia, municipalities are responsible for maintaining adequately capable fire services and are required to prepare and regularly update fire protection needs plans (Brandschutzbedarfspläne). The legal framework therefore explicitly connects the organization of the fire service with local conditions and planning. ¹

One of the most important dimensions of this planning is the time between an alarm and the arrival of the required emergency forces.

The widely used AGBF protection-goal definition specifies that, for a standard fire scenario, at least ten functions should arrive at the incident within eight minutes after notification of the fire service. Five minutes later, a total of sixteen functions should be available. These protection goals are generally assessed with a target achievement rate of 90 percent. ²

These numbers turn accessibility into something much more concrete than a map of circles around fire stations.

An eight-minute target does not mean that every location exactly eight minutes away is equally well served. It means that the road network, the station locations and the available resources have to work together as a system.

Accessibility analysis makes that system visible.

Why Accessibility Matters

A fire statgereralion creates a service area, but that service area is not circular.

Two buildings that are only a few hundred metres apart as the crow flies can have very different emergency travel times. A railway line, river, motorway, restricted access road or one-way system can create substantial detours.

Conversely, a location that looks relatively distant geometrically may be very quickly accessible if it is directly connected to a suitable road.

This is why simple buffer analysis is often insufficient for emergency-service planning.

A proper accessibility analysis can answer questions such as:

• Which population can be reached within eight minutes?
• Which areas remain outside the target travel time?
• Which station is the fastest station for a given location?
• How much population loses coverage if a station is closed?
• Where would an additional station improve coverage most?
• How much does a change in the road network affect accessibility?
• Which areas are served only because of a particular station?
• Where do several stations provide overlapping coverage?

The last question is particularly important.

A station may appear to have a large catchment area, while in reality most of that area can already be reached faster by another station. Conversely, a relatively small station catchment may contain strategically important areas that have no alternative coverage.

Accessibility therefore provides a way of evaluating redundancy, overlap and vulnerability, rather than simply measuring distance.

From Circles to Travel-Time Networks

Traditional accessibility maps often use distance buffers or simple travel-time polygons.

Modern network-based analysis can go much further. The fundamental object is a directed road network. Each road segment can carry attributes such as:

• length
• direction
• road type
• maximum speed
• surface
• gradient
• bridge characteristics
• traffic conditions
• built-up intensity
• intersections
• traffic signals

A travel-time function converts these characteristics into an estimated traversal time.

For a given fire station, a shortest-path algorithm can then determine the fastest route through the network to every relevant location.

In this tool, the analysis is performed on a 100 m population grid. Grid cells are connected to the road network through permitted access points. Where a cell does not contain an appropriate connection point, the model connects it to the nearest permitted junction and adds a final access leg.

This distinction matters.

A motorway may be geographically very close to a residential area, but that does not mean that a fire truck can leave the motorway directly into that area. The model therefore separates the question of which roads can be driven on from the question of where a population cell or fire station can enter the network.

The result is a much more realistic representation of accessibility than a simple Euclidean buffer.

Technical Background

The interesting part, however, is not the shortest-path algorithm itself. Shortest-path algorithms are well understood and computationally efficient. The more difficult question is:

How do we estimate realistic travel times for the individual road segments?

This is where many accessibility applications become difficult to inspect.

Commercial and closed-source applications can provide highly sophisticated travel-time models. They may incorporate detailed network data, traffic information and years of engineering experience.

But from an analytical perspective, there is a fundamental problem: the calculation can become a black box.

A user may be able to enter locations and receive an accessibility map without being able to inspect how the travel time was actually produced. The resulting model may contain substantial know-how, but that know-how is also precisely what makes independent methodological assessment difficult.

An open approach changes this relationship. Instead of treating the travel-time model as an opaque service, the function can itself become part of the analysis. In this application, the travel-time function is explicitly exposed. An individual directed road segment provides attributes such as its length, slope, road type, surface, maximum speed, traffic factor, built-up intensity, intersection characteristics and traffic-signal information.

The function converts these attributes into seconds. That means the model is not hidden behind an API. It can be inspected. It can be modified. And, most importantly, it can be calibrated.

Calibration Is the Real Challenge

Having an open model does not automatically make the result better. An openly published but poorly calibrated travel-time model can be less useful than a proprietary model with excellent empirical performance.

The important question is therefore not simply whether the source code is available. It is whether the assumptions can be confronted with reality. Observed travel times provide a way to do exactly that.

For example, observed emergency-vehicle trips, floating-car data, GPS traces or other trajectory-based measurements can be used to compare predicted and observed travel times. Parameters of the travel-time function can then be adjusted to reproduce real-world travel behaviour.

This creates a transparent calibration loop:

1. define the travel-time function,
2. calculate travel times,
3. compare them with observed journeys,
4. identify systematic deviations,
5. adjust the model,
6. validate it against independent observations.

The advantage is not that the model becomes magically perfect. The advantage is that its imperfections become measurable. This is an important distinction between model transparency and simply publishing a map.

A transparent accessibility analysis should make it possible to ask why a particular location received a particular travel time.

What Has Changed Computationally?

There was a time when analyses of this type required substantial computational infrastructure. Today, that assumption is increasingly outdated.

Modern browsers can perform surprisingly demanding numerical computations locally. Typed arrays, efficient memory management, binary data structures and optimized shortest-path implementations make it possible to work with sizeable road networks and population grids without sending every calculation to a remote server.

The application therefore uses the browser not merely as a display layer. The browser is the computational environment.

Road-network data can be loaded into memory, edge costs can be calculated, shortest paths can be determined, accessibility can be assigned to population cells and statistics can be generated directly on the user’s machine.

The result is a fundamentally different architecture from a conventional web application.

Instead of:

browser → server → database → calculation → server → browser

the workflow can become:

browser → local data → local calculation → local result

The server is reduced to distributing the application and its model data.

Local by Design

This architecture has an important consequence for sensitive planning questions. Consider a fire protection needs assessment. The locations of existing fire stations may be operationally relevant. Proposed locations may be sensitive. Scenario analyses may reveal vulnerabilities in the current emergency-response system.

With a conventional cloud-based application, these locations may be sent to an external server for processing. With a local browser-based application, that does not have to happen. Once the application and required model data are available, the station locations can remain on the user’s own machine. The calculation takes place locally. The resulting accessibility values are generated locally. The scenario therefore does not need to leave the browser. This is not merely a privacy feature.

It is also a question of digital sovereignty.

Municipalities, research institutions and emergency services do not necessarily need to outsource every spatial analysis to an external platform simply because the calculation is computationally complex.

For many applications, the necessary computational capacity is already sitting on the desk of the analyst.

The Fire Station Accessibility Lab

The Fire Station Accessibility Lab is a small demonstration of this idea.

The application allows fire stations to be placed directly on the map and evaluates their accessibility across a 100 m population grid.

Multiple stations can be activated or deactivated. This makes it possible to investigate scenarios such as:

• the current station configuration,
• the removal of an existing station,
• the addition of a proposed station,
• different combinations of active stations,
• the effect of different travel-time assumptions.

The map can show the fastest arrival time or the station that reaches each location fastest. The application also distinguishes between what an individual station can reach and what it actually wins against the other active stations.

This is important because accessibility is fundamentally a network property. A station’s value cannot be understood independently of the other stations.

Accessibility of fire stations

The application is deliberately not designed as a black-box planning service. The travel-time function is visible. Its parameters can be changed. Stations can be switched on and off. The maximum travel-time threshold can be modified. The resulting population and area statistics can be inspected and exported.

This makes the application useful not only as a calculator, but also as a laboratory for understanding how accessibility results emerge.

From a Map to a Planning Instrument

The most interesting potential of this approach lies beyond the visualization itself.

Once the calculation is transparent and reproducible, accessibility becomes something that can be integrated into broader planning workflows.

For example, a municipality could compare several potential station locations and ask how each affects:

• population coverage,
• spatial coverage,
• overlap between stations,
• areas without any accessible station,
• accessibility within a defined protection goal,
• redundancy of the station network.

The same infrastructure can also support sensitivity analysis.

• What happens if the assumed travel speed is reduced?
• What happens if a particular road class is excluded from station access?
• What happens if the maximum target time changes from eight to ten minutes?
• What happens if a station has a systematic delay before departure?

These are not merely technical parameters. They represent assumptions about the real emergency-response system.

Making them explicit allows the analyst to distinguish between:

what the data says,

what the model assumes,

and

what the planning decision ultimately requires.

Open Does Not Mean Simplistic

There is sometimes an implicit assumption that open tools are useful mainly because they are cheap. That is too narrow a definition. The more important advantage is that an open analytical workflow can make the entire chain of reasoning inspectable. Data can be inspected. Network construction can be inspected. Travel-time functions can be inspected. Calibration can be inspected. Scenario assumptions can be inspected. And the final accessibility measure can be reproduced.

This is particularly relevant for public-sector decisions. A map showing that a location is “within eight minutes” can look highly authoritative. But the number itself is only as meaningful as the model that produced it.

If the calculation is transparent, the discussion can move from “the software says so” to “these are the assumptions, this is the data, and this is how the result was calculated.”

That is a much stronger basis for evidence-based planning.

Local Computing as an Alternative Architecture

The Fire Station Accessibility Lab therefore illustrates a broader development in spatial analysis. The important technological change is not simply that browsers have become faster. It is that the traditional distinction between “web application” and “desktop analysis” is becoming less meaningful. A browser can now be the interface, data environment and computational engine at the same time.

For accessibility analysis in general, this creates an interesting architecture:

open model + local data + local computation + interactive interface

instead of:

closed model + remote service + opaque calculation + static result

Neither architecture is universally superior. Commercial systems can provide excellent data, mature workflows and sophisticated functionality. But there is now a realistic alternative for organizations that require transparency, reproducibility and control over their analytical infrastructure. And importantly, this does not necessarily require a large computing cluster. For many regional accessibility problems, modern local hardware is sufficient - so smartphones are.

Closing Remarks

Fire station locations are strategic infrastructure. Their effectiveness depends not only on where the stations are located, but on how quickly they can reach the population they are intended to protect. Accessibility analysis provides a way to make that relationship measurable.

In North Rhine-Westphalia, where municipalities are required to maintain capable fire services and prepare fire protection needs plans, such analyses can provide an important spatial component of the planning process. The established protection-goal framework makes travel time particularly relevant: the difference between eight and thirteen minutes is not simply a difference between two colours on a map, but can represent a fundamentally different level of emergency response.

Modern computational methods make it possible to calculate these relationships in considerably more detail than simple distance buffers. But computational power alone is not the decisive improvement. The more important step is making the model transparent.

A travel-time model should not have to remain a black box merely because it contains sophisticated know-how. If its assumptions can be expressed explicitly, tested against real observations and calibrated transparently, the resulting analysis becomes easier to understand, challenge and reproduce.

The Fire Station Accessibility Lab is a small example of this principle. It is not intended to replace professional fire protection needs planning. Instead, it demonstrates what becomes possible when accessibility analysis is treated as an open computational model rather than as an opaque software service.

And perhaps most importantly, it demonstrates that sophisticated spatial analysis does not necessarily have to happen somewhere else. It can happen here. On the analyst’s own machine. With the data under their control. And with every calculation visible.

References

Citation

If you cite this post, please use:

@online{holthaus_20261002_20261002_Overlapping_Accessibility,
  title   = {Overlapping Accessibility: The Fire Statio Example},
  author  = {Holthaus, Tim},
  year    = {2026},
  month   = {10},
  day     = {02},
  url     = {https://me.timholthaus.com/posts/stories/20261002_overlapping_accessibilit/}
}