Final Project: Who Can Walk to the Metro in Tashkent?

Measuring how much of Tashkent the metro actually reaches on foot, which districts are left to the bus, and whether the bus-dependent parts of the city also get the thinnest bus service. Built from OpenStreetMap and a gridded population raster, with walking times computed along the real street network.

1. Topic, Goals, and Questions

The topic

Tashkent runs two transit systems that behave nothing alike. The metro is fast, punctual and unaffected by traffic, but it exists at only 49 stations. The bus network reaches almost everywhere — on the order of two thousand stops — but is slow, crowded and hostage to the same congestion as private cars. Whether a household has a metro station within walking distance is therefore not a small difference in convenience. It decides whether the whole city is available to them on a weekday evening, or only their own end of it.

That divide has been moving. The metro spent three decades as two and a half lines through the Soviet-era core; since 2020 it has grown by an above-ground ring and a southern extension, and the stations added in that push serve a very different kind of neighbourhood than the ones opened in 1977. Nobody has published a map of what that expansion actually bought, counted in residents rather than in kilometres of track.

This project builds that map. For every populated 100-metre cell in the city it computes the walking time — along real streets and footpaths, not straight lines — to the nearest metro entrance, the nearest bus stop, and the nearest bazaar. It then classifies each cell as metro-served, bus-only, or beyond walking distance of either, and aggregates those classifications into population-weighted statistics per district.

Why the bazaar is in this project

A conventional "15-minute city" study measures the walk to a supermarket. In Tashkent that is the wrong destination: daily food shopping happens at the bazaar, and the large bazaars — Chorsu, Alay, Farhod, Kuyluk — are also the transfer nodes where the bus network is densest. Including bazaars as a third destination class makes the analysis mean something locally, and it supplies an independent check: if a district's residents can walk to a bazaar but not to transit, that says something real about the shape of the city rather than about how the metro happens to be drawn.

Visualization goals

• Show where metro walking access ends, at a finer grain than any district average can express — a station catchment boundary falls in the middle of neighbourhoods, not along administrative lines.
• Reduce the divide to one defensible headline number: the share of residents within a ten-minute walk of a station.
• Make bus dependency a visible geography in its own right, rather than the leftover space on a metro map.
• Test whether bus-dependent areas are compensated with denser bus service or penalised twice.
• Let a reader find their own neighbourhood and read its numbers directly.
• Keep the uncertainty visible — walking-time assumptions and OSM completeness are shown, not smoothed away.

Intended audience

Three groups, in order of how much the design owes them. Tashkent residents comparing neighbourhoods, who need to find one place on a map and read one number. Transport planners weighing where a further metro extension or a bus-priority corridor would serve the most people, who need the per-station and per-district comparisons. Researchers and NGOs working on urban service provision in Central Asia, who need the method and its caveats stated plainly enough to reuse. The finished site should be readable in Uzbek and Russian, not only English.

Research questions

1. Coverage. What share of Tashkent's population lives within a 5-, 10- and 15-minute walk of a metro entrance?
2. Bus dependency. Which districts are effectively bus-only — what share of each district's residents can walk to a bus stop but not to any metro station?
3. Double disadvantage. Do bus-dependent areas get denser bus service to compensate, or do they also have the fewest routes per stop? This is the question most likely to produce a finding that is not already obvious from looking at a metro map.
4. What the expansion bought. How much population did the post-2020 ring and southern extension bring within walking distance, and which individual stations serve the most walk-up residents — and the fewest?
5. Transit versus daily life. Does walking access to a bazaar coincide with walking access to transit, or are they two different maps of the same city?
6. Method sensitivity. How much do the headline shares change when a straight-line buffer is replaced by a true network isochrone? Railways, canals and the arterial ring roads should make that gap large in specific, nameable places.

2. Datasets

OpenStreetMap — transit stops, destinations, city structure

Source: Overpass API, ODbL licence.
Acquisition: Python requests, one query per feature class over the bounding box 41.16, 69.11, 41.40, 69.42; every response cached to disk so the pipeline reruns without hitting the API again.
Processing: pair bus stops that represent opposite sides of one road, attach metro entrances to their parent station, extract per-stop route counts from route relations, reproject to EPSG:32642.
Key attributes: name, name:ru, name:uz, railway, station, public_transport, highway=bus_stop, amenity=marketplace, route relation membership.
Size: roughly 2,200 transit stop features, about 100 bazaars, 11–12 district polygons, and the full walkable street network.

WorldPop — gridded population

Source: WorldPop, CC BY 4.0.
Acquisition: direct download of uzb_ppp_2020_UNadj_constrained.tif — 11.8 MB, no API key required.
Processing: window to the Tashkent bounding box, sample non-empty cells to points, join each point to its district polygon.
Attributes: cell centroid, estimated residents, district.
Size: roughly 30,000 populated 100-metre cells. This is the analysis unit — every headline number in the project is a population-weighted statistic over it.

Geofabrik extract — walking network for isochrones

Source: Geofabrik, ODbL, rebuilt daily.
Acquisition: uzbekistan-latest.osm.pbf, 118 MB, fed to a local OSRM instance running the foot profile in Docker.
Processing: the /table endpoint returns many-to-many walking durations from population cells to candidate stops in batches. Walking speed is fixed at 4.8 km/h and stated explicitly wherever a figure in minutes appears.

Official district population — validation only

Source: Open Data Portal of Uzbekistan and the State Committee on Statistics.
Use: WorldPop is a model. Official district totals are used to check that the raster sums to a believable city, and the ratio is reported rather than hidden. Results are not rescaled unless the discrepancy proves large, in which case the rescaling is documented.
Size: twelve rows, two variables. Small, and worth it.

Wikidata — metro station opening years (stretch)

Source: Wikidata SPARQL endpoint, P1619 (date of official opening) for stations of the Tashkent metro.
Use: research question 4 only. If coverage turns out to be patchy, the fallback is a hand-checked table of the four construction eras (1977–91, 2001, the 2020 ring, the southern extension) — a dozen rows, verifiable by hand.
Risk: this is the one dataset the project can lose without losing a question outright. Question 4 degrades from a year-by-year curve to a four-way comparison.

Verified feature counts

Counts cover nodes, ways and relations over the Tashkent bounding box. The metro station count was re-queried against the live Overpass API on 6 September 2026 and returned 49 nodes, 0 ways, 0 relations. The remaining rows come from the earlier scoping run; the endpoint rate-limited further queries, so re-verifying them is the first task of week 2 rather than a claim made here.

Three data problems, stated up front.

Bus stops are double-counted. A single kerbside location is usually mapped twice, once per direction of travel, and sometimes a third time as a public_transport=platform. This rules out count-based metrics such as "stops per square kilometre". It barely affects distance to the nearest stop, which is why the project is built on distance rather than counts — the same reasoning that makes the metric robust also makes pairing the stops an improvement rather than a precondition.

Tashkent has twelve districts, and OpenStreetMap may still show eleven. Yangihayot was split from Sergeli in 2020. If the boundary relation is absent we either digitise the split or report the two together and say so. Silently publishing a stale eleven-district geography would be the worse error, particularly since Yangihayot is exactly the kind of peripheral district this study is about.

Bus route relations are incomplete. Route counts per stop are a lower bound, not a census. Research question 3 rests entirely on this layer, so week 3 includes an explicit completeness audit; if coverage is too thin to support a service-level claim, the question is dropped rather than answered badly.

3. Analysis and Visualization Methods

Tools

• Python — requests for Overpass, geopandas and shapely for geometry, rasterio for the population raster, scipy.spatial.cKDTree for the straight-line baseline and for candidate pre-filtering, pandas for aggregation.
• OSRM in Docker, foot profile, for network walking times via the /table endpoint.
• D3.js v7 with d3-geo, topojson-client and d3-scale-chromatic on a static page — the same stack as the labs, no build step.
• TopoJSON for boundary delivery; the grid ships quantised so the page stays under a couple of megabytes.

Processing and analysis

1. Resolve stops to walkable access points. For the metro this means entrances, not station centroids: a Tashkent station spans a wide intersection and its entrances can sit 150 metres apart, so walking to the centroid systematically misstates access for the households in between. Where entrances are not mapped, the station node is used and the substitution is flagged in the data rather than absorbed silently.
2. Pair bus stops representing one location on two sides of a road, by clustering within 30 metres and requiring names to match, then keeping one access point per pair.
3. Reproject everything to EPSG:32642 (UTM 42N) so distances come out in metres. Computing distance in unprojected degrees is the single most likely way to produce numbers that are wrong but plausible.
4. Sample the population raster to points, drop empty cells, join to districts.
5. Straight-line baseline. KD-tree nearest-neighbour distance from every populated cell to each destination class. It runs in seconds and gives a working end-to-end pipeline in week 3, before any routing infrastructure exists.
6. Network isochrones. For each cell, take the eight nearest candidates by straight line, ask OSRM for walking durations to all eight, keep the minimum. Pre-filtering is what makes 30,000 × 2,000 tractable; taking eight rather than one guards against the case where the nearest stop is on the far side of a railway.
7. Classify every cell at each threshold: metro-served, bus-only, or neither. This three-way classification is the project's core derived variable and feeds four of the six views.
8. Aggregate into population-weighted district statistics and city-wide cumulative access curves.
9. Service level per stop — count distinct route relations serving each stop, then take a population-weighted median route count for the bus-only population of each district. Question 3 is answered by plotting that against bus-only share.
10. Sensitivity. Report every headline figure both ways, straight-line and network, and name the places where the two diverge most. The divergence is a result, not an error term.

User tasks supported

4. Visualization Sketches

Six views, each a different design idiom, sharing one selection state. They are ordered as an argument — where access ends, who is left on the bus, how many people that is, which districts, which stations, and whether service compensates — rather than as a gallery.

What links them. One selected district and one walking threshold are shared global state. Hovering a district in the stacked bars highlights it in both maps and in the scatter; dragging the threshold slider moves the access surface, the classification, the stacked bars and the marker on the cumulative curve together. Without that linkage these are six charts about transit. With it they are one instrument.

5. Group Roles and Responsibilities

To be completed. Replace the placeholder names below before submission. The split assumes three members; if the group is a different size, routing and D3 are where an extra person helps most, since those are the two longest critical paths.

Shared by everyone: all three review the full pipeline and can explain any part of it under questioning. Encodings, colour scales and the narrative order of the six views are decided together, because those carry the analytical argument rather than merely displaying it. Each member writes the section of the final documentation covering their own work.

6. Interim Presentation Deliverables

By the interim presentation we expect to demonstrate:

• A reproducible acquisition pipeline — one script rebuilds every layer from the public APIs, with responses cached so the demo does not depend on Overpass being reachable in the room.
• A cleaned stop dataset: raw versus paired bus stop counts, metro entrances linked to stations, and the raw-to-distinct collapse ratio reported as a result in its own right.
• Initial exploration — the distribution of walking distances by mode, per-district summaries, and the OSM completeness audit that decides whether research question 3 survives.
• At least two working D3 views reading committed real data, not mock values: the access surface map and the ranked district composition bars.
• One headline number, said out loud — the share of Tashkent's residents within a ten-minute walk of a metro entrance, with straight-line and network estimates side by side if routing is running by then, and the straight-line figure alone if it is not.
• Refined questions, with anything the data turned out not to support explicitly dropped rather than quietly downgraded.

The bus-stop pairing problem will be presented as a solved methodological challenge rather than hidden. It is the clearest example of why the analysis is built on distance rather than counts, and explaining it is the fastest way to show that the numbers on the slides mean what they claim to mean.

7. Timeline and Milestones

Scheduling risk, and the hedge against it. The data is static — OpenStreetMap and WorldPop will look the same in week 6 as in week 2 — so nothing external forces early progress. Two rules guard against that. The week 3 straight-line number is a hard internal deadline: it produces a complete, presentable pipeline with no routing infrastructure at all, so the project always has something true to show. The network isochrones in weeks 5 and 6 are then an upgrade to a working system rather than the thing everything waits on. OSRM is the only component that could fail outright, and it can fail without taking a research question with it — question 6 simply becomes a limitation instead of a finding.

Limitations

• Walking time is modelled, not measured. A fixed 4.8 km/h ignores summer heat, the lack of shade along the new ring's above-ground sections, crossings of eight-lane arterials, and how much harder all of it is with a pushchair. The isochrones are an optimistic upper bound on access and are labelled as such.
• Proximity is not service. We found no public GTFS feed for Tashkent in the open feed catalogues, so there is no headway or frequency data: a stop served twice an hour and one served every four minutes look identical here. Route count per stop is a proxy for service level, and a weak one. Every claim resting on it is stated as such.
• OpenStreetMap completeness is uneven. Metro stations are reliably mapped, bus stops less so, bus route relations least of all. If mapping density tracks district wealth, the bias runs in exactly the wrong direction for a study of disadvantage. This is audited in week 3 and reported alongside the results, not in a footnote.
• WorldPop is a model, not a census. Sub-district population is an estimate; nothing is reported to more than two significant figures, and district totals are checked against the official statistics.
• This is an access study, not an equity study. No reliable district-level income data exists for Tashkent, so the project reports the access disparity the data does show and leaves causal claims about who lives where to the discussion.

Data sources

Overpass API — OpenStreetMap query endpoint
WorldPop — gridded population estimates
Geofabrik — Uzbekistan OSM extract
OSRM — open source routing engine
data.gov.uz — Open Data Portal of the Republic of Uzbekistan
Wikidata SPARQL — metro station opening dates

Map data © OpenStreetMap contributors, ODbL. Population data © WorldPop, CC BY 4.0. Distances computed in EPSG:32642 (UTM 42N); walking times at 4.8 km/h along the OSM pedestrian network.