I kicked things off by pointing out that the Airport MRT seems to run six separate stopping patterns:
- 00- — Direct/Express, calling only at A1, A3, A8, A12, A13
- 00* — Peak-hour extended express with two extra stops (A18, A21)
- 00◇ — Peak skip-stop local (A21→A18→A13→A12→A9, then all stations to A1)
- 00 — Commuter (calls at all stations)
- 00△ — Airport-bound Commuter (A1→A13 and A22→A12, all stations, supplementary)
My question: does each pattern warrant its ownroute_master, given I wanted to attach Wikidata items to them?
System Map — Xy1904312, CC BY-SA 4.0, via Wikimedia Commons
1. Taoyuan Airport MRT — route_master scoping
Consensus reached: per the OSM wiki on route_master, variants that differ only in which stops they serve — not in destination — can share one master. A separate master is only warranted for genuine branching. On this basis, the top-level relation (6937084) was split into two masters, 普通車 Commuter and 直達車 Express, with sample Wikidata-linked tagging proposed:
name=桃園國際機場捷運
type=network
wikidata=Q4268353
name=普通車
type=route_master
wikidata=Q141252869
network:wikidata=Q4268353
Participants noted the broader tradeoff: this level of granularity is essentially train-grade classification — accurate but maintenance-heavy, especially without automation. A related prior effort to model Taiwan HSR’s numbered-train relations had similarly gone stale after schedule changes.
2. Extended case — Through-running cases, Tokyo as example
Japan has one of the world’s most extensive rail networks, and correspondingly one of the most extensive systems of inter-operator through-running (直通運行) — trains that cross from one company’s line onto another’s rather than staying within a single operator’s route. The Chuo Rapid/Chuo-Sōbu comparison opened into a longer discussion of how to model this in Tokyo specifically (e.g., trains crossing between Tobu, Keisei, Keikyu, Toei, Tokyu, Seibu, and subway lines at hubs like Oshiage and Ikebukuro).
A recurring observation: OSM’s public transport tagging scheme was shaped largely around European and UK rail/transit conventions, where a route staying within one operator’s line is the norm — so it doesn’t map cleanly onto systems built around routine inter-operator through-running. A more inclusive schema, better accommodating operating models like Japan’s, was raised as something worth pursuing rather than forcing through-running services to fit the existing single-operator assumption. As one participant put it, half-jokingly, once the conversation turns to railways, Japanese railway systems always becomes the lingua franca.
The core tension in practice: treating every destination combination as a route variant risks pulling large portions of the network into shared relations, with routes whose endpoints fall outside their “home” line — comparable to Seoul Line 1.
Options considered:
- Add each through-service to every operator’s relevant master — workable but can misrepresent a route’s ownership.
- Model by “operating system” (per common Japanese rail terminology), grouping interlined services as one unit rather than by individual operator.
- A dedicated “運用/交路” (duty-cycle/circulation) relation whose members are the individual routes composing one through-running trip — proposed as a cleaner structural fix.
Complicating factors raised: differing rolling-stock range restrictions per operator, and cases (e.g., Seibu Ikebukuro Line trains via Tokorozawa) where a single service can terminate under three different line identities depending on final routing.
As an interim, scoped step, alignment work began with the Airport Railroad Express (AREX) relation (15825720).
3. Side discussion — GTFS, multilinestring, and minimal PTv2 modeling
A tangential idea was raised: OSM’s multilinestring relation type could, in principle, auto-merge path fragments between stations — but only as a layer built on top of full GTFS timetable data, not a replacement for it; without such data, automated route assembly isn’t feasible. A minimal alternative was also discussed — PTv2 relations defined only by stop sequence, without full path geometry — with the caveat that routing between stops would then need to be inferred rather than mapped explicitly.
Reflist
Edits referenced in the thread
- Changeset
188771163— segment splitting work - Changeset
188777885— Fixed mislabeledalt_nameon relation 6937084 - Changeset
188868939— Peak-hour patterns with additional stops (r21376206) were reviewed as not require separateroute_master - Changeset
188808065— Top-level relation created to link the network, with the Green Line set to launch in Q4 2026.- Relation
21376293Taoyuan Metro
- Relation
Relations referenced
- Relation
11382519— Tokyo Metro - Relation
9841063— Guangzhou Metro Line 3 - Relation
8691899— Seoul Metropolitan Subway Line 1 - Relation
15825720— Airport Railroad Express (AREX), used as an alignment reference to Airport MRT
Others
- Telegram channel — chat
- Wikidata