Madrid Transit Access

1  Run identity

Every figure in this document belongs to one run. A run is identified by a content hash of its inputs, its parameters and the source code that produced it, so two runs of different code cannot claim the same identity, and a re-run whose output changed cannot silently reuse an old one.

The licence register hash is recorded but is deliberately not part of the run identity: correcting a licence changes what may be done with the output, never the output itself, and folding it into identity would force a full recompute to record a URL.

2  What this layer measures, and what it does not

Every figure describes scheduled service: what the operators' published timetables say runs, on one representative service day. That is a deliberate choice. Accessibility, planning and site-selection questions ask what service a location is provided with, and a schedule-based answer is stable, reproducible from public data, and recomputable by anyone who doubts it.

It does not measure whether services ran on time. No realtime feed, vehicle position or arrival observation is used anywhere in this layer. Punctuality is a different question and needs a different input. A reader who wants reliability will not find it here, and no figure in this document should be presented as if it answered that.

The unit of analysis is a 250 m cell of the INSPIRE reference grid in EPSG:3035, the statistical grid European reporting already uses, so results align with other layers and with Eurostat geographies without resampling.

Feed currency, stated plainly. 1 of 6 timetable feeds in this run had passed the end of their published validity before the service day: gtfs_metro_madrid, valid to 2026-05-27, 63 days before. The operator had not republished at the time the inputs were locked, so the most recent published timetable was used and the gap is recorded here rather than left for a reader to derive from §7.1. Where a lapsed feed still described unchanged service the effect is nil; where service changed in the interval, figures for that operator are out of date by that margin.

3  Method

3.1 Walk access

Each cell takes an analysis point, and walking times are computed over a pedestrian network derived from OpenStreetMap rather than as straight-line distance. Two quantities are published per cell: time to the nearest stop of any kind, and time to the nearest frequent stop, the second computed separately for each time window because a stop that is frequent at 08:00 need not be at 21:00.

3.2 Departures per hour

For each stop and route, scheduled departures within a window are counted and divided by the window's length. Where a feed encodes service as headways rather than as individual trips, the headway is converted arithmetically. The figure is per direction: a rider travels one way, so their service is that direction's, not the sum of both. A cell's figure aggregates the stops within walking range.

3.3 Access index (PTAL)

The access index follows Transport for London's Public Transport Accessibility Level method. Each stop within walking range contributes an equivalent doorstep frequency, EDF = 30 / TAT, where TAT is total access time — walk time plus half the average headway. Contributions are weighted and summed, so the index reads as “departures per hour effectively arriving at this doorstep”. It is reported against TfL's published band thresholds rather than a scale invented here, which is the point of using an established method: the number is comparable to a body of existing practice.

3.4 Population reach

Reach columns count residents reachable within 30, 45 and 60 minutes door to door, combining walking, waiting and in-vehicle time. Population is apportioned from the Global Human Settlement Layer's modelled residential grid.

3.5 Population, and why our figure is higher than the census

Residential population comes from the Global Human Settlement Layer, a modelled 250 m grid, apportioned to cells. It is not a census count, and it does not match one:

The modelled figure is the higher one, and that is the expected direction. A settlement-layer model estimates people present from built form and survey data; a municipal register counts people who have registered. Residents who have not registered, or who registered elsewhere, appear in the first and not the second.

Which one drives the map: the modelled figure, because it is the only one available per 250 m cell — a register total is a municipal number and cannot be apportioned to a grid without inventing a distribution. Every population-weighted statement in this layer, including the headline median and the share of residents in each class, is therefore modelled. The registered total is recorded beside it in every run so the gap is measurable rather than discovered.

Where this matters: absolute headcounts carry the model's error, so "N residents are worse than 10 minutes from frequent service" should be read as an estimate. Comparisons between cells are far more robust, because the same model applies to both.

3.6 Null policy

A real zero, an absence of service and a data failure are three different states and are kept distinguishable. A cell with no nearby stop is served by nothing; a cell whose inputs failed carries an explicit reason rather than a zero. Collapsing these would make a blank cell unreadable — the reader could not tell good news from missing data.

4  Parameters and where each came from

Every parameter carries one of two labels, and the distinction is not cosmetic. A specification value was transcribed from the customer's own written specification, whose hash is recorded in §1. A plan default was chosen by us: it is changeable without code, and it is never presented as though the specification required it. A parameter that is neither is a defect, and the labels below are read from the run's own manifest, not asserted here.

6 specification-derived, 32 plan defaults.

4.1 Specification-derived

4.2 Plan defaults — ours, and changeable

5  Validation against the operators' own figures

Internal tests check this pipeline against itself, which is the weakest kind of assurance available: a reference implementation written by the same author from the same assumptions can share a defect with the thing it validates. The comparison below is external. Every published figure comes from Metro de Madrid, EMT, Renfe, Metros Ligeros de Madrid or CRTM — recorded with its URL, a verbatim quote and the date it was retrieved, and hash-pinned so the comparison cannot be made to pass by editing what an operator said.

Operators publish a range — “every 7 to 10 minutes” — rather than a single figure, so a result counts as agreeing when it falls anywhere inside the published range. Bands are rounded conservatively: lower bounds up, upper bounds down, so rounding can never move one of our values into agreement.

5.1 By mode

5.2 Every disagreement, named

These are unresolved. They are published here rather than omitted, because a validation section that shows only agreement tells a reviewer nothing they can check.

6  Validating the model, not only its input

§5 checks departures per hour against what operators publish — that validates the input. These two check what is built on it.

6.1 Walk times, against an independent router

Stale evidence. This evidence was measured on run 75fd42f29bfe. This document describes run aad4ae941323. The figures below are that other run's.

Every walk figure comes from our own router over OpenStreetMap footpaths. Valhalla — a separate implementation — was asked for the same origin and the same destination stop, over the same extract, at the same walking speed, so a disagreement is a router disagreement and nothing else.

0 could not be routed by Valhalla, and 2 were excluded as routing artefacts — walks either router put beyond an hour to a bus stop, which is not a walk anyone takes. They are listed in the evidence file rather than averaged into the figures above.

6.2 Door-to-door journeys, against the operators' own planners

Thirteen journeys across Madrid were recorded from EMT's and Renfe's own planners before this pipeline produced any reach output. A corpus compiled after seeing your own answer is not evidence; this one predates ours.

Two things this comparison is not. The planners answer “if I leave now”; we answer “typically”, as a percentile over a departure window, which makes us slower on long, infrequent journeys by construction. And the works grouping is confounded — every affected pair is also among the longest and most peripheral — so it separates neither. No pass/fail band is declared: a journey time is a point, not a published range, and choosing a tolerance after seeing the numbers is choosing one that passes.

7  Sensitivity to the parameters we chose

§4 says which parameters are ours. This says whether they matter. Each row moves ONE parameter and leaves the rest identical; every figure is the population-weighted mean absolute change, because a cell with four residents moving 300% is not a finding and one with 4,000 residents moving 5% is.

Scope: Family A only (walk, frequency, access index, stop count). Family B (opps_*) is not swept — it would cost a full RAPTOR sweep per arm.

The largest movement, read plainly. walk_speed_m_per_min is a plan_default — a value we chose, not one the specification fixed. Its value in this run is 80.0, and moving it by -10% moves the access index by 4.30% of its value, population-weighted. A reader who thinks that value should be different should read every access-index figure in this document as carrying about that much movement per -10% of disagreement.

8  Quality gate

A run records the checks that ran and what each returned. The gate distinguishes a check that passed from one that was never evaluated, because “not evaluated” reported as a pass is how an unverified number reaches a client.

9  Sources, licences and required attribution

Each input carries a written licence position, held once in a register whose hash is recorded with the run.

1 source has no settled redistribution position: aoi_polygon. Until settled, this layer is provisional for redistribution: the figures stand, and the terms on which a third party may receive them do not. What each open position blocks is stated against that source in the table below. It is said here rather than left to be inferred from a table.

9.1 Timetable feeds in this run

9.2 What each source permits, and the credit it requires

10  Known limitations

• Scheduled, not observed. No realtime data is used. See §2.
• One service day. Figures describe a representative day, not an annual average. A public holiday, a strike or engineering works are not represented.
• Population is modelled. Residential population comes from a modelled global settlement grid apportioned to cells, not from a census count per cell.
• 8 of 41 comparisons disagree with the operator's published figure and are unresolved. They are listed in §5.2 rather than omitted.
• Walking network from OpenStreetMap. Coverage is very good in Madrid but is volunteer-maintained, and a missing footpath makes a cell look worse served than it is.