PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung

Das wird die Qualität des ÖPNV-Mappings im Münchner Stadtgebiet (U-Bahnen, Trams, städtische Busse) sicherlich verbessern.

Noch etwas Geduld, dann stehen sie bei PTNA als separater GTFS-Feed zur Verfügung.

Uiii, auf einmal ???
Seis drum, Ärmel hoch
Wie kann ich helfen ?

Gruss derBeKri

Z.B. die Routen vergleichen “IST” (in OSM) zu “GTFS”

Z.B. Bus 62 Ostbahnhof => Rotkreuzplatz

“GTFS” : https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?feed=DE-BY-MVG&release_date=&trip_id=100.T3.3-62-G-012-1.9.R

“IST”: https://ptna.openstreetmap.de/relation.php?id=196239&lang=de (hierin in der Karte oben rechts die “Stops” und “Platform-Route” ausblenden)

Die beiden Karten sollten nahezu identisch sein.

Ist etwas mühselig sich durch all die Varianten durch zu klicken. Aber mir ist noch keine gute Idee gekommen, wie ich das in PTNA automatisieren könnte.

“IST” bekommst du, wenn du auf https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html in der Spalte “Relation (id=)” jeweils passend auf “PTNA” klickst

“GTFS” bekommst du, wenn du dich auf https://ptna.openstreetmap.de/gtfs/DE/routes.php?feed=DE-BY-MVG durch die Linien und dann dort in der zweiten Spalte durch die “Trip-ID” klickst

Gruß
Toni

Da gibt es sicherlich eine Menge Ansätze … aber da ja so vieles Wichtiges (selbst bei) “PTv2” “optional” oder “recommended”, nicht aber “mandatory” ist, kann man sich auf nichts verlassen.

  • stop_position ist “recommended if available” (noch nicht einmal : mandatory if existing)

  • platform ist “recommended if available” (noch nicht einmal : mandatory if existing)

  • ways sind mandatory

somit: eine leere Relation ist nicht erlaubt. Die ‘mandatory’ ways taugen allemal zum “rote Linie malen auf Karte” - aber das Thema hatten wir ja schon öfter.

In GTFS haben wir die lat/lon der ‘platforms’, wäre ja zu schön, wenn die ‘platforms’ bei OSM “erforderlich” wären - dann könnte man vergleichen.

Aber evtl. kommt mir ja noch eine Idee.

Interessant, eigene route_id für Fahrten am 24.12. :slight_smile:
Woher kommen denn die Shapes?

Mir hat eine Zuordnung der route_id in der Analyse über die optionalen GTFS Felder der .xml-Datei im OSM-Wiki meist geholfen. Analog kann diese Information in OSM mit gtfs:route_id=*, gtfs:release_date=* (optional) und operator:guid bzw. network:guid bzw. gtfs:feed=* eingetragen werden.

Na ja, zumindest stop_position oder platform sollte schon in der Relation vorhanden sein, wenn auch oft ein Mix aus jeweils einzeln oder auch als Pärchen. Wenn es um die Haltestellen geht sollte ref:IFOPT bzw gtfs:stop_id die erste Wahl sein. Funktioniert aber auch nur gut, wenn in den GTFS-Daten bis auf Steig-Ebene Angaben vorhanden und die Haltestellen in OSM entsprechend gepflegt sind. Problem habe ich noch bei unterschiedlichen Ids für die gleichen Steige von unteerschiedlichen Quelle.

Keine Ahnung, habe noch nicht genauer rein geschaut.

Das ist halt das Problem: sogar innerhalb einer Relation mal so, mal anders.

Da kann man sich nicht auf die Platforms fokussieren, wenn die mal nicht drin ist, dafür aber deren Stop-Position.

Aber andererseits: entweder platform oder stop_position sollten (als n-te Haltestelle) drin sein und deren Position (center oder mindestens ein node bei way/area, …) sollten jeweils der erwarteten GTFS-Position (der n-ten Haltestelle) nahe kommen - Distanz < x Meter.

Problem: wie groß sollte ‘x’ sein? Vor allem klein genug um in Busbahnhöfen noch falsche “Steige” erkennen zu können - also ~ 1 - 1.5 mal Buslänge oder 1.5 - 2 mal Busbreite?
Damit ließe sich die korrekte Reihenfolge und Vollständigkeit (nicht zu viele, nicht zu wenige und die richtigen) der Haltestellen prüfen

ref:IFOPT oder gtfs:stop_id sind weitere, nachgelagerte Prüfungen.

Aber wie so oft: Der Teufel steckt im Detail und false-positives / falsche Fehlermeldungen sind nicht zielführend/motivierend.

Sorry, habe erst jetzt bemerkt, dass ich den Satz nicht ganz verstanden habe.

“.xml-Datei im OSM-Wiki”?

Meinst du die RVF-Linien, … die CSV-ähnlich strukturiert sind?

Ziel ist, diese Feed/Route-ID-Angaben in den CSV-Daten mit den gtfs:feed, gtfs_route_id und gtfs:trip:id:sample in den Relationen zu nutzen um eine(n) (wie auch immer gelagerte) Prüfung / Quercheck durchzuführen. Aber das ist eine von mehreren Baustellen in PTNA.

Hi Toni,

gut wäre wenn die PTNA bei der Pärchenbildung irgendwie unterstützen könnte :confused: Also ein Trip aus dem GTFS mit den vorhandenen Relationen…

Ich mach das umständlich und unscharf mit Skript und Calc-Tabelle so lala…

Gruß Miche

Wäre machbar (, Herr Nachbar).

Sofern keine gtfs:trip_id:sample Informationen in der Relation sind könnte ich die GTFS-Route-ID aus der Kopfzeile nehmen und versuchen eine Routenvariante zu ermitteln die von der Anzahl der Stops, deren Position (Anfang?, Ende?, die Weiteren), deren Namen … her zu einer der Trips passt.

Ist dagegen gtfs_trip_id:sample in der Relation gegeben, so kann eine direkte Prüfung der Relation gegen den Trip gemacht werden - auf änliche Weise.

ja die IDs haben das Problem das die nicht stabil sind und von Jahr zu Jahr sich ändern und nur in der GTFS Ausgabe einmalig sind. :confused: Namen sind auch unterschiedlich geschrieben oft Abgekürzt. Position auch nicht immer perfekt…

Aber es wäre was wenn man eine Relation in das gleiche Format zum GTFS bringt… wie z.B. hier…

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?feed=DE-BY-MVV&release_date=&trip_id=10.T0.19-226-s22-1.1.R#stoplist

pro Haltestelle einen Listeneintrag… (nicht zwei, drei oder nochmehr…), lan/lat der platform (keine ID eines Way oder sowas) und das für ein Skript lesbares Format… :wink: und alle Relationen in einer Datei(wäre auch gut)… das wäre ein Traum. Dafür brauch ich bis jetzt >100 Zeile Code… mit Problemen.

Wie wäre es hier

https://ptna.openstreetmap.de/relation.php?id=7164138&lang=de

siehe unter “Platforms”.

Das selbe sogar für Route-Master

https://ptna.openstreetmap.de/relation.php?id=812416&lang=de

siehe unter “Others”.

mit einem Button “Export Platform Infos als CSV”

N.B.: wobei ich die Darstellung für Route-Master gerade das erste Mal selber sehe (bisher nie probiert) und überrascht bin, dass, und was, da raus kommt.

ja/nein… da wird auf OSM-ID der platformen verlinkt… da muss ich wieder jedes Objekt bei der API abfragen ( == blöd :confused: ) lat/lon wäre gut… das ich da mit einem wget-Befehl… möglichst vorgekaute Daten bekomm… um mich dann dem vergleichen zuwenden kann.

Ist das richtig? zweimal “Sigmund-Riefler-Bogen”, einmal Node und einmal Way
https://ptna.openstreetmap.de/relation.php?id=13547415&lang=de

oder wo anders hab ich platform ohne Name=* gehabt…

Sorry, hatte mich nicht präzise ausgerückt:

  • “Export als CSV” mit Name, lat, lon, ref:IFOPT, … (jeweils wenn vorhanden)

Nein, nur ein Mal bitte. “Platform” sollte immer eine gerade member-Nummer, “Stop” immer eine ungerade member-Nummer haben.

Ausnahmen: S-Bahnen: z.B. Marienplatz: von links einsteigen, nach rechts aussteigen: 2 * Platform == spanische Lösung.

Und genau solche Dinge machen eine Analyse schwierig, wenn man falsche Fehlermeldungen vermeiden will/muss.

Ja genau :slight_smile: lat/lon hab ich wenn die platform eine Fläche/Weg ist immer die lat/lon der ersten Node des Ways genommen…aber kann man auch anders machen.

ja… genau… da gibt es zu viele Ausnahmen und Sonderfälle…

Oh, sorry, da habe ich glatt das Format durcheinander geworfen. Hast völlig Recht CSV-ähnlich.

Ja, so hatte ich das auch gemeint. :slight_smile:

Kenne jetzt nicht die Genauigkeit der Daten in München, bei mir kannst Du solche Berechnungen vergessen. Nicht alle Haltestellen sind bis auf Steigtiefe definiert, die Position ist häufig zu ungenau gerade wenn ich Haltestellen am Busbahnhof und welche auf dem Land vergleiche. Hinzukommen Haltestellen an mehrspurigen Straßen in beide Richtungen mit Bushaltebuchten. Bei drei Spuren in beide Richtungen plus Bucht ist die stop_position auf der Straßenmitte schon mal etliche Meter von der realen Position entfernt.
Wie schon erwähnt taugt der Name auch nicht wirklich, daher bin ich so schnell bei ref=*, local_ref=*, ref:IFOPT oder gtfs:stop_id