OSM Data

OpenStreetMap provides community-maintained public transport data. We fetch Swiss PT nodes and their route relations via Overpass API.

Way Ingestion Policy (Issue #37)

In addition to OSM nodes, we now ingest a narrow subset of OSM ways as virtual stop elements.

Included way categories:

1. aerialway=station + public_transport=station
2. ways with uic_ref where no existing node has the same uic_ref

Kept ways are converted to virtual IDs (way_<osm_way_id>) and represented as point elements using out center from Overpass (or a centroid fallback in parser logic). These virtual IDs are propagated through matching and route membership the same way as node IDs.

Statistics

• OSM Nodes with Route Data: 0

Data Source

Node Selection Criteria

Generated Route Artifacts

The raw XML currently feeds two output families: entity-first route tables for route import, plus flattened/sidecar files used by stop-level matching and stats helpers.

Entity-first route tables

Flattened / sidecar stop-level files

Alongside the entity-first tables, the wider pipeline also maintains two per-node exports:

osm_nodes_with_routes.csv

One row per node–route combination. This compact flattened view uses these columns:

This CSV is a flattened export used by route stats/UI helpers. The matcher itself reads route memberships directly from the OSM XML relation pass in OsmState.from_xml_file().

osm_directions.csv

One row per node with an extracted textual direction (by node Name or UIC reference):

Direction Extraction

OSM routes often have a ref_trips tag encoding direction:

• .H suffix → outbound (direction_id = 0)
• .R suffix → inbound (direction_id = 1)

Many routes lack this tag, leaving the exported direction_id / direction_id_derived empty. In the in-memory matcher, relations without a detectable suffix are expanded to both directions so GTFS token matching can still fall back to route ID alone.

Key OSM Tags for Matching

Operator Normalization

OSM operator names vary widely (for example, CFF, FFS, and SBB CFF FFS for SBB). These are normalized before matching—see 1.3.1 OSM operator normalization.

Overpass Query

The following Overpass QL query is used to fetch the data from the Overpass API:

[out:xml][timeout:360];
area["ISO3166-1"="CH"]->.searchArea;

(
    node(area.searchArea)["public_transport"~"platform|stop_position|station|halt|stop"];
    node(area.searchArea)["railway"="tram_stop"];
    node(area.searchArea)["amenity"="ferry_terminal"];
    node(area.searchArea)["amenity"="bus_station"];
    node(area.searchArea)["highway"="bus_stop"];
    node(area.searchArea)["railway"="halt"];
    node(area.searchArea)["railway"="station"];
    node(area.searchArea)["aerialway"="station"];
)->.pt_nodes;

(
    way(area.searchArea)["aerialway"="station"]["public_transport"="station"];
    way(area.searchArea)["uic_ref"];
)->.candidate_ways;

.pt_nodes out body qt;
.candidate_ways out body center qt;

(
    relation(bn.pt_nodes)[type=route];
    relation(bw.candidate_ways)[type=route];
);
out meta;