Fehlerhafte ref:IFOPT Einträge (insbesondere in Bayern)

Im Rahmen des Projekts “BEG - Barrierefreiheit4ÖPNV” wurden in Bayern neben Barrierefreiheitsinformationen auch umfangreich die mastscharfen DHIDs (Deutschlandweite einheitliche Haltestellen-Identifikation, siehe VDV 432) als ref:IFOPT eingetragen.

Grundsätzlich ist das m.E. begrüßenswert, jedoch ist hierbei öfter die Straßenseite vertauscht worden.

Im (inoffiziellen) zHV-issues repository, in dem allgemeine Fehler zum zentralen Haltestellenregister dokumentiert werden können, habe ich hierzu Issue 26 angelegt und die zu diesem Projekt in OrganisedEditing/Activities angegebene BEG-/Mentz-Kontaktadressen angeschrieben.

1 Like

ja sowas hab ich auch schon mal ausgewertet… Abweichung der im GTFS und OSM position… dabei schon einige Fehler mal korrigiert… aber es gibt auch Fehler im GTFS-Dateien von daher ist manchmal nicht nachzuvollziehen was da jetzt richtig ist oder… ist nur nur eine “nr.” die vor Ort nicht feststellbar ist.

Allgemein bzw. finde ich Arbeit ganz gut… dadurch sieht man erst wie viele Haltestellen fehlen in… und das sind sehr viele…

Gruß Miche

Das muss man immer im Hinterkopf haben, wenn man OSM mit GTFS vergleicht.

Ich arbeite gerade an GTFS/OSM und GTFS/GTFS Vergleich und werde die Beta-Version hier im Forum diese Woche noch vorstellen

Vorab: “Compare GTFS route with OSM route_master

Wenn man in die Tabelle klickt kommen schon reale Daten

In die PTNA-Analyse kommen diese Links
grafik
auf reale Vergleichs-Daten (GTFS-trip/OSM-route) dann auch rein:

Wobei in der Kopfzeile oben rechts und beim Route-Master die Links auf GTFS-route/OSM-route_master Vergleiche noch fehlen.

Ui, grundsätzlich ein cooles Feature nur killen mich aktuell die paar tausend Änderungen an den paar tausend Relationen, die ich seit Mitte Dezember in der Schweiz aktualisiert habe… :see_no_evil:

Eine erste Frage wäre, ob wir die Namensprüfung (allenfalls mittels Flag?) einzeln aussetzen können. Dies da wir beispielsweise im Kanton Zürich systematische Abweichungen zwischen den zerhackstückelten BAV-Namen (uic_name) und den geringfügig weniger zerstückelten ZVV-Namen (ref_name, name) haben. Beispiel “Zürich Enge, Bahnhof” ist im ZVV “Zürich, Bahnhof Enge” und an den Haltekanten effektiv als “Bahnhof Enge” angeschrieben. Und gelegentlich steht zudem “Bhf.” statt “Bahnhof”, was vor Ort oft ausgeschrieben wird und in OSM immer. Dies produziert ebenfalls false-positives und wartet nur darauf, dass ein User, der OSM mit einem Spiel verwechselt einfach dummbatzig umändert, “weil das Tool dies ihm sagt”…

Ich weiss… Luxusprobleme… :wink:

Das Problem mit den Namen haben wir beim DE-BY-MVV vermutlich in einem noch schlimmeren Ausmaß. Daher gibt es beim Import der GTFS Daten in PTNA schon immer eine “Normalisierung”. D.h. aus “str.” wird “straße” bzw. In CH “strasse” und so weiter. Auch aus “Taufk., W.-Messerschmitt-Str.” wird dann “Taufkirchen, Willy-Messerschmitt-Straße” und so weiter. Die Liste ist jetzt schon recht lang und wohl nie vollständig und das Konzept skaliert noch nicht. Aber da lässt sich was machen.

Sollten wir zum Thema Namensabweichungen vlt einen eigenen Thread starten? Auf https://gtfs.mfdz.de/delfi/ weise ich größere Namensabweichungen mit MATCHED_THOUGH_NAMES_DIFFER aus (z.B. hier für München).

Häufigste Gründe für Abweichungen:

  1. In OSM sind Steigangaben als Bestandteil des Namens erfasst (sollte ich vlt nicht monieren, wenn wie z.B. "Pasing, Bahnsteig 2) Teil einer benannten stop_area(?))
  2. im zHV werden für Teilbereiche einer Haltestelle abweichende Namen nicht gesondert ausgegeben (z.B. heißen die S-Bahn Halte von de:08111:6056 Stadtmitte (wie im zHV die Station insgesamt), während die Bus/Stadtbahn-Haltestellen defacto Rotebühlplatz heißen)
  3. Tatsächliche Schreibweisenunterschiede aufgrund Umbenennungen
  4. mitunter auch mal fehlerhafte Matches (bitte Rückmeldung, wenn ihr welche findet)
  5. Abkürzungen/Suffixe