Fehlermeldungen bei Busrouten

Communities Deutschland (Germany)
1

Von einem Mapper-Kollegen wurde ich auf folgende Seite zur Prüfung der Busrelationen hingewiesen:
https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#A2.5.8
Da musste ich feststellen, dass bei den von mir angelegten oder überarbeiteten Relationen (ab Bus 541) etliche Dinge beanstandet werden. Insbesondere zwei Punkte sind häufig angeführt:

  1. Der erste Punkt bzw. der letzte Punkt des Weges ist keine ‘stop_position’ dieser Route
  2. PTv2 Route: ‘name’ sollte annähernd die Form ‘… ref …: from => to’ haben
    Zu 1.
    Ich wollte beim Anlegen der Relationen kurze Straßenstücke nicht weiter aufsplitten, um die Anzahl der kurzen Stücke in Grenzen zu halten. Sonst erhalte ich Straßenstücke von wenigen Metern, wenn der Bus gleich nach dem Start oder am Ende der Linie in ein anderes Straßenstück einmündet. Deshalb sind kurze Stücke vor der ersten bzw. nach der letzten Haltestelle noch Teil der Relation.
    Nach meiner Kenntnis können bei einer Bushaltestelle sowohl eine „stop_position“ auf der Fahrbahn als auch eine „platform“ neben der Fahrbahn angelegt werden, es reicht aber auch einer der beiden Punkte. Als Anwender der OSM-Karte kann ich aber nur sehen, in welche Richtung der Bus fahren wird und wo ich auf ihn warten muss, wenn das Bussymbol auf der Karte neben der Fahrbahn sichtbar ist. Deshalb habe ich bei neueren Haltestellen zum Teil nur die „platform“ statt nur „stop_position“ verwendet. Dies würde aber selbst bei einem aufgesplitteten Straßenstück wohl ebenfalls als Fehler angesehen werden, da ja der Punkt „stop_position“ auf der Fahrbahn fehlt.
    Zu 2.
    Bei der Namensvergabe der von mir angelegten Relationen habe ich mich an anderen Namen orientiert, da ich im Wiki nichts Eindeutiges gefunden habe. Ich wollte auch nicht einfach nur eine Zahl (z.B. 551) vergeben, da bei einer Linie mit Hin- und Rückfahrt etliche Relationen anfallen und ich sie ohne einen Zusatz im JOSM-Editor im Relationen-Fenster nicht leicht unterscheiden kann. Aber selbst eine einfache Zahl wird teilweise als Fehler, teilweise aber nicht angesehen.
    Deshalb meine Fragen, bevor ich ans Überarbeiten der Relationen gehe:
  3. Ist bei der Bus-Relation am Beginn und Ende unbedingt der Node „stop_position“ zu setzen und nicht nur die „platform“ und ist an der Stelle des „stop_position das Straßenstück unbedingt aufzusplitten?
  4. Wie genau soll der Name der Busrelation lauten, um nicht als Fehler angesehen zu werden und er trotzdem einen Hinweis zur Unterscheidung im JOSM-Editor enthält? Bei den nicht von mir angelegten Routen wird z.B. der Name von VVS_502_1, VVS_531_1 und VVS_534_1, nicht beanstandet, aber selbst die Namen 532 und VVS_535_1 ohne weiteren Zusatz werden wieder beanstandet. Was ist also korrekt?
    Gruß ghostrider44
2

Lass mich als Autor von PTNA antworten:

Das Argument könnte man bei so vielen Features wie lanes=, turn:lanes=, maxspeed:forward=, maxspeed:backward=, parking::= und vielen mehr anbringen.
Mach’ dir da keinen Kopf, spalte auf, wo es notwendig ist. Die verschiedenen Software (Renderer, Navis, …) müssen eh mit sowas umgehen können und die Länge und Anzahl sollte denen nichts weiter ausmachen.

So ist es, stop_positionen sind optional (so wie platforms auch), wenn aber mindestens eine stop_position in der Relation drin ist, so wird von PTNA erwartet, dass auch am Anfang und Ende der Route stop_positionen sein sollten: “alles oder nichts” könnte man sagen.

Für train, tram, … ist bei einigen Auswertungen von PTNA “–relaxed-begin-end-for=train,tram,light_rail” gesetzt, so dass für diese Fahrzeuge nicht gemeckert wird (Endstation eines Zuges im Kopfbahnhof, die Strecke geht bis zum Puffer, …). Allerdings muss die erste/letzte stop_position immer noch auf dem ersten/letzten Way liegen (Anzahl stop_position > 0, s.o.).
Für ‘bus’ halte ich das nicht für sinnvoll - Wege, wo keine Passagiere befördert werden gehören mMn nicht in die Relation (auch wenn sie noch so kurz sind).
PTNA wertet die Länge übrigens nicht aus - und ab welcher Länge sollte man meckern?

  • bei Route-Master wird nicht weiter geprüft

  • bei Route:

  • name = “… ref …: from => to”

  • name = “… ref …: from => via [=> via] => to”

PTNA stützt sich auf

und legt diese an einigen Stellen strenger aus (recommended/optional wird zu: “PTNA erwartet das”).

Dass PTNA an einigen Stellen strenger ist liegt daran, dass man mit dem “absolut Notwendigen” (=mandatory) im realen Leben in der Regel nicht weit kommt.

Wir hätten den heutigen Mobilfunkstandard nicht, wenn die Hersteller sich bei der ersten Version (GSM) nur an die ‘mandatory’ Features gehalten hätten.
Die ‘optionalen’ Features sind das Salz in der Suppe, vom ‘madatory’ wird man gerade mal satt, mehr aber auch nicht.

3

Hier sollte ich wohl mehr sagen:

Diese Formen werden so von den beiden Spezifikationen genannt.

“<Linientyp/Zugattung> : => ”

Wobei ‘Start’ und ‘Ziel’ den ‘from’ und ‘to’ Werten der Relation entsprechen (bzw. in ‘from’ und ‘to’ jeweils enthalten sein müssen)

Wenn es zwei Routen mit identischem ‘from’ und ‘to’ aber abweichenden Wegen gibt, so sollten wenige geeignete ‘via’-Werte (durch Semikola ohne Blanks getrennte Namen von Haltestellen) gesetzt werden, und diese in ‘name’ wieder auftauchen.

Beispiel https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_221

Edit: Beispiel hinzu

4

Vielen Dank für die Antwort. Mit der Fehlerbeseitigung konnte ich so beginnen.
Durch die PTNA-Prüfung konnte ich übrigens auch einige andere Fehler beseitigen, die ich durch andere Prüfungen nicht festgestellt habe. Durch die Angabe “PTv2 Route: hat Lücken” konnte ich in der Reihenfolge vertauschte Wegstücke, eine als Einbahnstraße in falscher Richtung eingetragene Zufahrt zu einer Bushaltestelle und einen neuen Kreisverkehr, der nicht in die Relationen aufgenommen war, feststellen und so die Relationen berichtigen.

5

Freut mich.

PTNA kann derzeit natürlich nur formale Fehler finden.

Eine mehr inhaltliche Prüfung benötigt natürlich externe Daten, die PTNA mit den OSM-Daten vergleichen kann - hier bieten sich GTFS-Daten an.

Für den VVS sind solche GTFS-Daten verfügbar und PTNA bereitet sie auch auf, diese bieten sich zur manuellen Prüfung der OSM-Daten an.

Man sieht bei den OSM-Daten, dass

  • die Reihenfolge der stop-Positionen und platforms noch nicht korrekt ist

  • 8 stop_positionen aber nur 7 platforms gemapped sind

Nächstes Ziel für PTNA wird sein, solche Prüfungen automatisiert zu erstellen, denn

  • die Reihenfolge des Haltestellen,

  • die Anzahl der Haltestellen und

  • die Namen der Haltestellen

kann man aus GTFS nehmen und mit den OSM-Daten vergleichen …

Wir sind noch in der Lernphase, wie die GTFS-Daten am besten mit OSM-Route-Relationen zu “verheiraten” sind, d.h. welche “gtfs:trip_id” welcher Relations-ID entspricht.

“Wir” sind, außer mir als Entwickler, ein paar engagierte, einfallsreiche, produktive und kritische Mapper und Nutzer von PTNA.

Kommentare, Anregungen, Kritik? Nur her damit!

VG Toni

Edit: URL von localhost auf https://ptna.openstreetmap.de/ geändert

6

Danke für die Hinweise.
Etwas ist mir noch unklar:
PTNA listet etliche Fehlende Linien auf, z.B:
Fehlende Linie für ‘ref’ = ‘552’ und ‘route’ = ‘bus’
Zum 1.1.2020 haben sich u.a. auch im Bereich Bietigheim-Bissingen zahlreiche Änderungen bei den Buslinien ergeben, insbesondere beim Betreiber der Linien, der Fa. Spillmann. Deshalb habe ich die Relationen der nicht mehr existierenden Linien, die meist in andere Linien integriert wurden, gelöscht bzw. umbenannt und aktualisiert. Wie kann ich nun diese Fehlermeldung noch loswerden?

7

PTNA macht eine SOLL-IST-Analyse.

  • SOLL, das was in Realität existiert

  • IST, das was in OSM existiert.

Das SOLL wird in einer CSV-Liste beschrieben, die im OSM-Wiki hinterlegt ist: https://wiki.openstreetmap.org/wiki/Stuttgart/Transportation/VVS-Linien-gesamt

Diese CSV-Liste kann und sollte von lokalen Mappern gepflegt werden. Hier könntest du korrigieren und Linien, die in Realität nicht mehr existieren löschen, neue Linien hinzufügen, …

Als Hilfestellung hierzu kann für den VVS auch wieder GTFS dienen: https://ptna.openstreetmap.de/gtfs/DE/routes.php?network=DE-BW-VVS
Einen manuelle Abgleich kann man damit schon mal machen, oder sich eine CSV-Liste erzeugen lassen (die aber in der Regel noch nachbereitetet werden muss).

8

Danke für die weiteren Hinweise. Man lernt im Alter doch noch etwas dazu. Jetzt habe ich aber gerade ein Brett vor dem Kopf:
Wie erhalte ich diese spezielle id

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BW-VVS&trip_id=1.T0.31-541-j20-1.1.H

für andere Routen. Die Änderung von z.B. 541 auf 551 zeigt hat keinen Erfolg.

9

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BW-VVS&trip_id=1.T0.31-541-j20-1.1.H

Mein Fehler, dabei hatte ich mehrere Schritte übersprungen …

Für den VVS startet du am besten hier:

Dort suchst du dir die passende Liniennummer aus (die auch noch zeitlich gültig ist), z.B. 551:

Und erhältst eine Übersicht über die verschiedenen Routenvarianten der Linie 551 - hier 18, die zum Teil Teilrouten andere Routen sind.

Du suchst dir die passende Variante aus (z.B. die 3. die ist schön lang) und landest auf der Seite mit der Karte …

Auf dieser Seite kommt man übrigens durch Klicks auf

  • “Linie 551” wieder einen Schritt zurück zur Übersicht über die Varianten des 551er

  • “DE-BW-VVS” wieder zurück auf die Übersicht der VVS-Linien

  • die deutsche Flagge zurück auf die Übersicht aller bei PTNA für DE verfügbaren GTFS-Daten

BTW: auf die kryptische Trip-Id = “5510007.T0.31-551-j20-1.23.H” habe ich keinen Einfluss, die kommt vom VVS.
Darin versteckt sich beim VSS aber

  • die Linie “551” in der Route-ID = “31-551-j20-1”
  • die Richtung “H” bzw. “R” (Hin- und Rückfahrt)
  • die Service-ID = T0, die Auskunft gibt über die Tage an denen der Bus fährt (nicht aber die Uhrzeiten)
  • … und einiges mehr
    Aber diese Systematik gibt es nicht bei allen GTFS-Quellen.
10

Vielen Dank.
Ich werde dies demnächst mal probieren. Mache erst mal ne Pause.

11

In der Liste
https://ptna.openstreetmap.de/gtfs/DE/routes.php?network=DE-BW-VVS
taucht die Buslinie 553 Bondorf - Mötzingen - Gründringen auf. Die Busnummern 500 bis 600 sind eigentlich alle im Bereich des Landkreises Ludwigsburg. Die 553 war hier mal eine Teilstrecke der 554.
Die meines Erachtens falsche Nummer ist auch hier zu sehen.
https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BW-VVS&route_id=76-553-j20-1
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BW-VVS&trip_id=6.T0.76-553-j20-1.1.R
Ich nehme an, dass die Nummer falsch ist. Wer kann dies überprüfen?

12

Solche Unklarheiten oder Diskrepanzen kann eigentlich nur ein lokaler Mapper erkennen.

Was mir auffiel ist, dass der 553er laut GTFS nur eine einzige Variante hat - ungewöhnlich.

Ich selber habe bisher noch keine fehlerfreien GTFS-Daten gesehen. Die Daten sind eigentlich mit Vorsicht zu genießen.
Der Vorteil der GTFS-Daten ist, dass sie in maschinenlesbarer Form vorliegen und man sich nicht durch Tonnen von Fahrplan-PDFs wühlen muss (sofern die PDFs lizentechnisch ebenfalls problemlos sind).

Bei neuen Quellen und Versionen ist es jedes mal spannend zu sehen wie die GTFS-Spezifikation interpretiert wurde und was nun schon wieder anders ist.

Die oben genannten GTFS-Daten stammen vom 23.03.2020 und wurden vom NVBW freigegeben - mit passender Lizenz.

Beim VVS selber gibt es mittlerweile GTFS-Daten vom 05.08.2020.
In der Version gibt es den Bus 553 nicht.

Bei den GTFS-Daten des VVS ist jedoch die Lizenz (“Creative Commons 4.0”) nicht so richtig passend zu unserem Einsatzzweck.
Daher habe ich sie noch nicht analysiert.

N.B.: andere Verbünde geben die Daten unter der selben Lizenz frei, allerdings mit dem Zusatz: “Die Daten aus unserem GTFS-Feed dürfen ausdrücklich für OpenStreetMap verwendet werden.” (MVV) oder “Wenn die Daten der Verkehrsverbund Berlin-Brandenburg GmbH (VBB) Bestandteil des OpenStreetMap-Datenbankwerkes werden, genügt eine Nennung des VBB in der Liste der Beitragenden.”