Genau so und die Reihenfolgenummer der Haltestelle sichtbar: dann kann man grobe Fehler in der Reihenfolge sofort sehen.
Diese Darstellung wäre optimal, setzt aber GTFS-Daten voraus, und dass ich zur OSM-Relation eine passende Trip-ID gefunden habe - das tag; “gtfs:trip_id=…” in der Relation hilft hier
Aber auch ohne GTFS als SOLL-Vorgabe und mit Nummerierung der Haltestellen und die rote dicke Linie auf Basis der lat/lon der OSM-Platforms in der gegebenen Reihenfolge … würde grobe Fehler sichtbar machen.
Und selbst ohne die rote Linie:
http://www.roeltgen.com/gpx/ibro_ol4ptgtfstestN47.html?ids=9041933
Hier fehlt im Westen “Dachau (S)” als Haltestelle, das weiß ich.
Oder aber die Frühlingstraße ist die erste Haltestelle und die Ways von Dacheu (S) bis Frühlingstraße davor sind überflüssig (was auch ein Fehler wäre).
Aber beide Ansätze gehen in die richtige Richtung.
Ich hatte auch schon überlegt, brouter mit den Positionen der Platforms zu füttern (kein eigenes JavaScript, … keine eigene Page, …) aber irgendwie sollten die OSM-Ways der Relation drunter liegen.
Was mir mittelfristig vorschwebt: die PTNA-Analyse bekommt beim Aufruf die Lage der SQLite-DB (die der GTFS-Analyse) mitgeteilt und kann versuchen eine Routen-Variante (Relation-ID) mit einer Trip-ID zu vergleichen: hinsichtlich Haltestellen-Position, -Name, -Reihenfolge, … bis hin zu “shapes” (sofern vorhanden).
Aber zu einer Relations-ID eine passende Trip-ID zu finden dürfte nicht einfach sein … ohne false-positive oder false-negative Match. …: “gtfs:trip_id=…” in der Relation würde etwas helfen.