You are not logged in.
- Topics: Active | Unanswered
Announcement
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***
#1 2021-12-13 16:43:09
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Die auf unserer Website bereitgestellten GFTS-Daten stehen Ihnen ohne Einschränkungen zur Verfügung, somit können Sie sie auch gerne für OSM nutzen.
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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#2 2021-12-13 19:45:22
- BeKri
- Member
- From: München, Aubing
- Registered: 2014-08-14
- Posts: 261
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Uiii, auf einmal ???
Seis drum, Ärmel hoch
Wie kann ich helfen ?
Gruss derBeKri
Offline
#3 2021-12-13 20:02:33
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Wie kann ich helfen ?
Z.B. die Routen vergleichen "IST" (in OSM) zu "GTFS"
Z.B. Bus 62 Ostbahnhof => Rotkreuzplatz
"GTFS" : https://ptna.openstreetmap.de/gtfs/DE/s … -012-1.9.R
"IST": https://ptna.openstreetmap.de/relation. … 39&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/D … lysis.html in der Spalte "Relation (id=)" jeweils passend auf "PTNA" klickst
"GTFS" bekommst du, wenn du dich auf https://ptna.openstreetmap.de/gtfs/DE/r … =DE-BY-MVG durch die Linien und dann dort in der zweiten Spalte durch die "Trip-ID" klickst
Gruß
Toni
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#4 2021-12-13 21:10:29
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Aber mir ist noch keine gute Idee gekommen, wie ich das in PTNA automatisieren könnte.
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.
Last edited by ToniE (2021-12-13 21:11:29)
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#5 2021-12-13 23:17:05
- skyper
- Member
- Registered: 2020-06-08
- Posts: 687
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Interessant, eigene `route_id` für Fahrten am 24.12.
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.
ToniE wrote:Aber mir ist noch keine gute Idee gekommen, wie ich das in PTNA automatisieren könnte.
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.
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.
Offline
#6 2021-12-14 00:21:33
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Woher kommen denn die Shapes?
Keine Ahnung, habe noch nicht genauer rein geschaut.
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.
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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#7 2021-12-14 10:15:33
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Mir hat eine Zuordnung der route_id in der Analyse über die optionalen GTFS Felder der .xml-Datei im OSM-Wiki meist geholfen.
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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#8 2021-12-15 15:31:59
- miche101
- Member
- Registered: 2008-12-16
- Posts: 1,297
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Hi Toni,
gut wäre wenn die PTNA bei der Pärchenbildung irgendwie unterstützen könnte 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
Offline
#9 2021-12-15 17:36:51
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
gut wäre wenn die PTNA bei der Pärchenbildung irgendwie unterstützen könnte hmm Also ein Trip aus dem GTFS mit den vorhandenen Relationen..
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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#10 2021-12-16 09:52:42
- miche101
- Member
- Registered: 2008-12-16
- Posts: 1,297
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
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. 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/s … 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... 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.
Offline
#11 2021-12-16 10:46:24
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
Wie wäre es hier
https://ptna.openstreetmap.de/relation. … 38&lang=de
siehe unter "Platforms".
Das selbe sogar für Route-Master
https://ptna.openstreetmap.de/relation. … 16&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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#12 2021-12-16 11:11:06
- miche101
- Member
- Registered: 2008-12-16
- Posts: 1,297
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
ja/nein... da wird auf OSM-ID der platformen verlinkt... da muss ich wieder jedes Objekt bei der API abfragen ( == blöd ) 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. … 15&lang=de
oder wo anders hab ich platform ohne Name=* gehabt..
Offline
#13 2021-12-16 11:37:11
- ToniE
- Member
- From: Ottobrunn, Bayern, Germany
- Registered: 2016-06-13
- Posts: 956
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
ja/nein... da wird auf OSM-ID der platformen verlinkt... da muss ich wieder jedes Objekt bei der API abfragen ( == blöd hmm ) lat/lon wäre gut.. das ich da mit einem wget-Befehl.. möglichst vorgekaute Daten bekomm.. um mich dann dem vergleichen zuwenden kann.
Sorry, hatte mich nicht präzise ausgerückt:
* "Export als CSV" mit Name, lat, lon, ref:IFOPT, ... (jeweils wenn vorhanden)
Ist das richtig? zweimal "Sigmund-Riefler-Bogen", einmal Node und einmal Way
https://ptna.openstreetmap.de/relation. … 15&lang=de
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.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben.
Offline
#14 2021-12-16 11:47:59
- miche101
- Member
- Registered: 2008-12-16
- Posts: 1,297
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
* "Export als CSV" mit Name, lat, lon, ref:IFOPT, ... (jeweils wenn vorhanden)
Ja genau 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.
Und genau solche Dinge machen eine Analyse schwierig, wenn man falsche Fehlermeldungen vermeiden will/muss.
ja.. genau.. da gibt es zu viele Ausnahmen und Sonderfälle..
Last edited by miche101 (2021-12-16 11:49:31)
Offline
#15 2021-12-16 17:00:32
- skyper
- Member
- Registered: 2020-06-08
- Posts: 687
Re: PTNA: GTFS-Daten der MVG (Teil des MVV) stehen uns zur Verfügung
skyper wrote:Mir hat eine Zuordnung der route_id in der Analyse über die optionalen GTFS Felder der .xml-Datei im OSM-Wiki meist geholfen.
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?
Oh, sorry, da habe ich glatt das Format durcheinander geworfen. Hast völlig Recht CSV-ähnlich.
skyper wrote:Woher kommen denn die Shapes?
Keine Ahnung, habe noch nicht genauer rein geschaut.
skyper wrote: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.
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.
Ja, so hatte ich das auch gemeint.
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üfenref: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.
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`
Offline