PTNA - News: GTFS-Analyse

Wobei der obere rein fahr-technisch nicht passt, falsch ist?

Ja des glaub ich auch… Wäre ungeschickt…

Heute hab ich die erste Haltestelle ein Problem mit dem runden gehabt. Dort war die Platform weit hinter der der MVV, weil die Platform beim Schutzhäuschen gemappt war. Das Schutzhäuschen war weit weg von der Straße… jetzt hab ich einen shelter type => öpnv gemacht und die platform näher der Straße gebracht

Korrekt, und dann gibt’s noch andere Unterschiede:

  • Bus 210: Hst Ortsmitte (südwärts) und Robert-Koch-Straße (nördlich der Straße) wurden letztes Jahr umgebaut (verlegt: 30 - >50m), in den GTFS-Daten aber nicht angepasst
  • Busse in Starnberg: z.T. erhebliche Abstände zwischen dem was in OSM gemapped ist und dem was GTFS sagt (was ist richtig?)
    ** “Starnberg, Landratsamt” ist definitiv falsch in den GTFS (nicht mehr gepflegte und unvollständige Liste von Fehlern: https://wiki.openstreetmap.org/wiki/M%C3%BCnchen/Transportation/MVV-GTFS#Fehler_in_den_GTFS-Daten)

Die Analyse von Stops: OSM vs. GTFS ist eine anderes Thema, dem sich Dietmar (okilimu) widmen will. Das hatten wir auf dem Hack-Weekend in Karlsruhe im Februar mal so besprochen. Evtl. basiert das dann auf einem Ansatz von Holger von mfdz.de (https://mfdz.de/blog/haltestellendaten-bw-vergleich-osm-nvbw)

Gruß, Toni

ich noch eine gefunden die bei mvv nicht richtig ist: ( ca.75m falsch )

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.07524%2C11.88546%3B48.07502%2C11.88640#map=19/48.07518/11.88595

Bus 442 :slight_smile:

noch eine sehr falsch ist… die hab selbst mal korregiert in OSM ca. 50m Falsch

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=48.31500%2C11.92148%3B48.31459%2C11.92128#map=19/48.31478/11.92146

unter anderen Bus 501

Bzgl. der Stops ansich: ich werde mal mit Dietmar Kontakt aufnehmen.

Da braucht’s eine andere Art von Auswertung als bei den Routen:

  • Lage der Platform (OSM vs. GTFS)
  • Name der Platform (korrekte Schreibweise, ref_name, …)
  • IFOPT (sofern bekannt, beim MVV ist die stop_id = IFOPT, bei anderen nicht …)
  • was fehlt in OSM
  • was ist in OSM zu viel
  • welche sind PTv2-konform
  • was ist mit SEV, Schulbussen?

Holger von mfdz.de hat da ja eine Python-basierte Analyse, die man evtl. anpassen könnte.
Die Analyse hat Daten nicht von GTFS, sondern von NVBW, und die CSV-Daten sind umfangreicher pro Haltestelle.
Die Analyse macht von dem ‘mehr’ an Daten Gebrauch, kommt also evtl. mit "reinem " GTFS nicht zurecht / nicht sehr weit.

Oder das man das möglichst einfach dem MVV melden könnte und die das in ihren Daten ändern und dann beim nächsten Gtfs dann richtig wäre :confused:

… und die wiederum an Mentz DV, ihrem Dienstleister.

Update:

:slight_smile: Download der Umgebung einer Haltestelle in Id oder JOSM

Bei der Anzeige der Details eines einzelnen Trips (Routen-Variante) kann man die Umgebung einer Haltestelle (deren GTFS-Koordinaten) in iD oder JOSM laden.

Beispiel: https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=28.T0.19-904-s20-1.10.H#stoplist

:frowning: In beiden Fällen ist nicht garantiert, dass die in OSM eventuell vorhandene Haltestelle sichtbar ist (liegt leicht außerhalb des Gebietes oder existiert nicht?).

:frowning: In beiden Fällen kann die Position der Haltestelle gemäß der vorliegenden GTFS-Koordinaten (derzeit?) leider nicht sichtbar gemacht werden.

:frowning: :frowning: In iD nicht möglich, bei JOSM nicht möglich ohne einen neuen (leeren?) Node in einer bereits geladenen Ebene zu erzeugen (z.B. und Achtung: http://127.0.0.1:8111/add_node?lat=48.0051715542916&lon=11.3477145359612 ), der beim Upload möglicherweise versehentlich mit hochgeladen wird :frowning:

An weitere Features wird gearbeitet.

Stay tuned …

Edit: ein Verweise auf ‘localhost’ nutzt niemandem was :roll_eyes:

Hi,

hab eine Kleinigkeit gesehen… in der Map(Tooltip) und GPX ist eine “(” Klammer am Namen :confused:

Gruß Miche

Danke, ‘(iD, JOSM)’ nun in eigene Spalte verschoben.

Update:

:slight_smile: Download der Umgebungen aller Haltestellen in JOSM

Bei der Anzeige der Details eines einzelnen Trips (Routen-Variante) kann man die Umgebung aller Haltestellen (deren GTFS-Koordinaten) in einem Rutsch in JOSM laden.

Beispiel: https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=52.T5.19-213-s20-1.2.R#stoplist

Das wird durch ein JavaScript erledigt, das entsprechend viele GET-requests an JOSM sendet (geht sogar erstaunlich flott).

Die Bounding-Boxes sind jeweils 30 m * 30 m um die GTFS-Koordinaten herum.

:expressionless: Ist noch experimentell - Feed Back erwünscht

:frowning: Hat noch einen Haken: die synchronen HTTP-Requests laufen noch im Main-Thread - was “nicht erlaubt” ist, aber funktioniert.

:frowning: Für Shape-Punkte gibt das noch nicht, kommt aber - je nachdem wie das Feed Back ausfällt.

Hallo Miche,

laut Wochennachrichten [1] hat Roland für Overpass-API ein paar Erweiterungen [2] eingeführt … von denen eine interessant ist:

Die von dir mal vorgeschlagene Overpass-API Query könnte man ändern:

Von:

[out:xml][timeout:25];
(
  nwr["public_transport"~"platform|stop_position"](around:50.0,48.1334650800486,11.7034371976669);
  nwr["highway"="bus_stop"](around:50.0,48.1334650800486,11.7034371976669);
  
  nwr["public_transport"~"platform|stop_position"](around:50.0,48.136930511474,11.7153080378443);
  nwr["highway"="bus_stop"](around:50.0,48.136930511474,11.7153080378443);
  
  nwr["public_transport"~"platform|stop_position"](around:50.0,48.143820912491,11.7232923109173);
  nwr["highway"="bus_stop"](around:50.0,48.143820912491,11.7232923109173);
);
out meta;>;out meta qt;

Nach:

[out:xml][timeout:25];
(
  nw(around:15.0,48.1334650800486,11.7034371976669);
  
  nw(around:15.0,48.136930511474,11.7153080378443);
  
  nw(around:15.0,48.143820912491,11.7232923109173);
);(._;>;<;);out meta;

Ich würde alle Nodes und Ways (und wg. ‘>’ alle Nodes der Ways) und
(wg. ‘<’) alle Eltern Relationen der Nodes und Ways erwischen

Aber … ich erwische nicht sämtliche Member der Relationen. D.h. nicht alle Member eines Flixbus “Paris ↔ Moskau”, sondern nur deren Member in den Aussschnitten. Das reduziert die Menge an Daten ganz gut.

Ich probiere das mal im Zusammenhang mit JOSM … bei shape-Punkten lediglich around:5.0 und …

http://127.0.0.1:8111/import?url=http%3A%2F%2Foverpass-api.de%2Fapi%2Finterpreter%3Fdata%3D......

Gruß
Toni

[1] https://weeklyosm.eu/de/archives/13090
[2] https://lists.openstreetmap.org/pipermail/talk/2020-April/084533.html

Ja ist geschmackts Sache :wink: Der eine möchte ein wenig mehr sehen der andere weniger…

Ich fände jetzt noch eine Routing Link wäre toll :sunglasses: …so als Erleichterung. :wink:

z.B. für https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=10.T0.19-210-s20-1.4.H

graphhopper.com
https://graphhopper.com/maps/?point=48.0409683110054%2C11.6614280160552&point=48.0463655186021%2C11.6587504785824&point=48.0515077526329%2C11.6550412219119&point=48.0524619811994%2C11.6614064633181&point=48.0537947184981%2C11.6650598307353&point=48.0557719221425%2C11.6676897375637&point=48.059129099637%2C11.6654814222769&point=48.0615969900852%2C11.6636542639945&point=48.0649804337512%2C11.6612305886031&point=48.067905442462%2C11.6589035446008&point=48.0712876988587%2C11.6561169596617&point=48.0742933373265%2C11.6537217015341&point=48.0783608239527%2C11.6515471512156&point=48.0894628087646%2C11.6440490755247&&locale=de&vehicle=car&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap

openrouteservice.org
https://maps.openrouteservice.org/directions?a=48.0409683110054%2C11.6614280160552,48.0463655186021%2C11.6587504785824,48.0515077526329%2C11.6550412219119,48.0524619811994%2C11.6614064633181,48.0537947184981%2C11.6650598307353,48.0557719221425%2C11.6676897375637,48.059129099637%2C11.6654814222769,48.0615969900852%2C11.6636542639945,48.0649804337512%2C11.6612305886031,48.067905442462%2C11.6589035446008,48.0712876988587%2C11.6561169596617,48.0742933373265%2C11.6537217015341,48.0783608239527%2C11.6515471512156,48.0894628087646%2C11.6440490755247,&b=4c&c=0&d=100&k1=de&k2=km

brouter.de/brouter-web
http://brouter.de/brouter-web/#map=12/48.0894628087646/11.6440490755247/standard&lonlats=11.6614280160552,48.0409683110054;11.6587504785824,48.0463655186021;11.6550412219119,48.0515077526329;11.6614064633181,48.0524619811994;11.6650598307353,48.0537947184981;11.6676897375637,48.0557719221425;11.6654814222769,48.059129099637;11.6636542639945,48.0615969900852;11.6612305886031,48.0649804337512;11.6589035446008,48.067905442462;11.6561169596617,48.0712876988587;11.6537217015341,48.0742933373265;11.6515471512156,48.0783608239527;11.6440490755247,48.0894628087646&profile=car-eco

Kann ich gerne machen … (nur) für den Fall, dass keine shape-Daten vorhanden sind?

Ja wenn shape Daten vorhanden sind… Braucht man es eigentlich nicht, aber schaden würd es auch nicht. Oder was meinst du?

Pro: manche shapes sind nicht vollständig, haben zwischen zwei (oder mehr) Haltestellen keine shapes …
Pro: man könnte brouter, graphhopper, OSRM mit shapes vergleichen und Abweichungen bewerten (die drei Router fahren z.B.nicht in den Busbereich in Neuperlach Süd rein)

Con: zu viele shape-Punkte würden u.U. die 8K-Grenze (oder wie hoch die auch immer ist) für GET-Requests sprengen

Viele shape-Daten basieren wohl auf OSM und haben als shape-Punkte die/alle Nodes der Ways über die gefahren wird … > 1000 Punkte habe ich schon gesehen.