You are not logged in.

#1 2021-12-13 16:43:09

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 942

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

MVG wrote:

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: 259

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: 942

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

BeKri wrote:

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: 942

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

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.

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: 681

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

Interessant, eigene `route_id` für Fahrten am 24.12. 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.

ToniE wrote:
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: 942

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

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.

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: 942

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?

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,296

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 hmm 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: 942

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

miche101 wrote:

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,296

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. hmm 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... 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.

Offline

#11 2021-12-16 10:46:24

ToniE
Member
From: Ottobrunn, Bayern, Germany
Registered: 2016-06-13
Posts: 942

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,296

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.


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: 942

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

miche101 wrote:

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)

miche101 wrote:

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,296

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

ToniE wrote:

* "Export als CSV" mit Name, lat, lon, ref:IFOPT, ... (jeweils wenn vorhanden)

Ja genau 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.

ToniE wrote:

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: 681

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

ToniE wrote:
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.

ToniE wrote:
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. smile

ToniE wrote:

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.

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

Board footer

Powered by FluxBB