PTNA - News: GTFS-Analyse

Super, danke :sunglasses:

Hi Toni,
mir ist gerade was untergekommen… da war via=…;…;… getaggt aber im name=* war kein Via. Weiss nicht ob du das prüfen magst, aber wollte dir nur sagen was ich gefunden hab :wink:

Gruß Miche

Danke … da war für den umgekehrten Fall eine if-Abfrage aber kein ‘else if’ für diesen Fall.

Gruß
Toni

PTv2 verlangt, dass die stop_position auf einem für das Verkehrsmittel geeigneten Weg liegt. Ansonsten ist es ein Fehler. Wenn der Weg nicht in der Relation ist, dann ist das kein Fehler … es ist nur verdächtig falls andere Wege da sind. Da gibt es öfter mal Fehler bei zwei Tram-Ways “auf” einem highway.

Ich halte jedes Routing der ÖPV-Verkehrsmittel für schädlich:

Wenn eine Brücke wegen irgendwelcher Probleme gesperrt wird und ein Mapper das einträgt, dann ist das völlig in Ordnung. Wenn ein Kartenprogramm dann irgendwelche Phantasierouten für Busse produziert, dann ist das nicht die Schuld des Mappers sondern der Kartensoftware. Ich werde mir solche Karten jedenfalls nicht ansehen. Was wir in so einem Fall brauchen, ist eine Fehlermeldung für die Route. Dann kann jemand ermitteln, wie der Bus jetzt wirklich fährt … welche Haltestellen ausgelassen werden … welche Ersatzhaltestellen eingeplant wurden … welche anderen Routen angepasst wurden um den Bedarf zu decken.

Alles klar.

  • Wenn es keine Ways in der Relation gibt, dann muss nicht auch noch gemeldet werden, dass eine stop_position nicht auf den Ways liegt - das ist zwangsläufig so.
  • Wenn es mindestens einen Way in der Relation gibt, so wird gemeldet, wenn eine stop_position nicht auf einem der Ways liegt.

Den letzten Halbsatz nach … :

  • die Ways sollen eine durchgehende und sortierte Strecke bilden, ohne Lücken
  • der erste Way muss mit einer stop_position beginnen, das muss die erste stop_position der Relation sein
  • der letzte Way muss mit einer stop_position enden, das muss die letzte stop_position der Relation sein
    → das wird momentan geprüft.
    → die Reihenfolge der stop_position in der Relation vergleichen mit der Reihenfolge, wenn man den Ways folgt: passt nicht immer, vor allem dann nicht, wenn es Schleifen gibt (Haltestelle mit selben Namen in beiden Richtungen,…).

Der letzte Satz: verstehe ich nicht ganz.

Gruß
Toni

Ich auch, d.h. die automatisierte Berechnung einer Route an Hand der Haltestellen um daraus eine Karte zu machen.

Das geht aber nicht ohne eine “Vorgabe”: d.h. ein Mapper macht eine PTv2-Relation und gibt an, wie die Route zu dem Zeitpunkt ist.

Eine Fehlermeldung beim Bau einer Brücke, … (sofern in OSM auch gemapped) meldet PTNA derzeit, weil highway=construction oder access=no (ohne psv=yes) sind.

Eine Abweichende Routenführung eines Busses (mit Auslassen von Haltestellen) wegen Baustellen (kurz-, mittel- oder langfristig?) bekommen wir mit, wenn Mapper “am Ball bleiben” und den Verkehrsverbund “beobachten” (Pressemeldungen, Webseite des Verbundes, …) - theoretisch (*).

GTFS mit oder ohne shapes bietet zumindest ansatzweise eine Möglichkeit OSM mit (halbwegs) aktuellen Daten der Verbünde zu vergleichen.

Die GTFS-Analysen bei PTNA sind (für mich) eine Vorbereitung dahin gehend, dass PTNA selber die Daten benutzt um sie bei der Analyse mit den OSM-Daten zu vergleichen.
Wie das optimal geht, wie weit das gehen kann, was man “rauskitzeln” kann? Ich weiß es noch nicht … ist aber spannend.

“Was soll der ganze Aufwand?” Mmh, solange Ptv2 und das ältere noch Bestand haben und kein neueres PTv-irgenwas kommt oder ÖPNV komplett aus OSM verschwindet ist es doch OK an sowas zu arbeiten.

Toni

(*) “In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon!” (Autor unbekannt)

Ja. Aber die stop_position muss auf einem zu den “xxx=yes”-Angaben geeigneten Way liegen … egal ob der Weg in der Relation ist oder nicht. Natürlich gibt es keine Pflicht, dass zu melden.

Ja. Das ist zwar kein Fehler (Routen dürfen ja unvollständig sein) aber eine interessante Sache.

Hmm. Wie alle anderen Haltestellen darf die erste und die letzte Haltestelle als “nur platform” oder “nur stop” oder “beides” eingetragen werden. Bei “nur Platform” ist da kein “stop” und das ist völlig OK.

Hatte ich auch schlecht formuliert. Bei Gleisen ist ja normalerweise jede Spur ein eigener Way und bei Straßen sind die Spuren in einem Way. Dadurch haben wir oft direkt nebeneinander drei Ways: einen für die Straße in der Mitte und Straßenbahngleise auf beiden Seiten direkt daneben. Der Stop der Straßenbahn (falls vorhanden) muss auf dem Gleis liegen und der Stop des Busses (falls vorhanden) auf der Straße. Beim Splitten der Wege in Straße und Gleise ist oft vergessen worden, auch die “Stops” zu splitten.

Interessant, die Prüfung ist noch nicht drin. Ein Bus kann nicht über Trambahngleise (ohne weiteres highway=) fahren und dort seine Haltestelle haben. Ein bus’ braucht ein ‘highway=’ > path|footway|cycleway|… (es sei denn, es steht psv|bus=yes dran), eine ‘tram’ braucht ein ‘railway=tram’

“Dürfen”, ja, sollten aber nicht, denn sonst sind sie irgendwie nutzlos. Aber: wie beurteile ich bei einer sw-technischen Prüfung, ob sie vollständig sind, alle Haltestellen hat, …?

Auch wieder wahr. Ideal wäre beides, aber wenn nur ‘platform’ dann müsste man suchen, ob das Ende / der Anfang der Fahrstrecke “recht nah” bei der letzten / ersten ‘platform’ liegt. “recht nah” == “< 20 Meter”?
IIRC, bei einer neueren Diskussion über “stop_position ist generell unnötig” wurde bzgl. 1. und letzte stop_position eine Ausnahme gemacht, was wiederum nicht konsequent zu “komplett ohne stop_position” ist - irgendwie braucht’s man dann doch mal wieder?

Verstanden, sehen wir oft in München, wo die Gleise in der Fahrbahn liegen, in OSM aber als zwei railway=tram rechts und links neben dem highway= liegen.
Das wird in PTNA erkannt, sofern bei einer Tram sowohl das “railway=” als auch die “Tram-stops auf dem railway=” in der Relation sind, für den Bus analog. Fehler würde man gemäß 1. Punkt oben heraus finden, ‘tram’ auf ‘highway=’ ohne ‘railway=’ und tram-stop auch auf highway.

ich finde die stop-position praktisch, wenn man z.B. Routing betreibt. Weil da kann es sein das die Platform einer anderen Straße näher steht, als der in der der Bus fährt… dann kann die stop-position die lat/lon der Platform für Routing ersetzen…

Z.B.

http://brouter.de/brouter-web/#map=19/48.19631/11.80997/osm-mapnik-german_style&lonlats=11.809898,48.196556;11.8093,48.19653;11.808774,48.196406&profile=car-eco

wenn man stop-position die lat/lon ersetzt würde es so ausfallen :slight_smile:

http://brouter.de/brouter-web/#map=19/48.19631/11.80997/osm-mapnik-german_style&lonlats=11.809898,48.196556;11.8093,48.196467;11.808774,48.196406&profile=car-eco

:sunglasses:

Na ja. Es kann auch die Haltestelle fehlen und der Weg drin sein oder umgekehrt. Oder jemand mappt die Haltestelle und traut sich nicht an die Relationen. Oder ist mit dem Bus gefahren und hat Haltestellen übersehen.

Beides zu mappen finde ich garnicht ideal. Viele mit einem einzelnen Node für beide Richtungen gut gemappte Haltestellen werden jetzt zu vier Objekten plus einer zusammenfassenden stop_area-Relation ohne dem Informationsgehalt irgendwas hinzuzufügen. Das war damals ein Kompromiss, der die “bus_stop auf die Straße” - und die “bus_stop neben der Straße” - Fraktionen von weiteren Edit-Wars abhalten sollte: “Wenn da schon einer den bus_stop an die für Dich falsche Stelle gemacht hat, dann kannst Du jetzt mit public_transport=xxx das andere Ding auch noch hinzufügen und es kommt dann gleichberechtigt in die Route”.

Aber da geht man doch von der Vorstellung immer vollständiger Routen aus. Es gibt bestimmt noch viele Länder, in denen man ganz klassisch ein Stück mit dem Bus fährt und Haltestellen markiert und notiert und diese Teile dann in OSM einträgt. Oder man kommt per Rad oder zufuß an einer Haltestelle vorbei und trägt sie in die Routen ein ohne die Fahrstrecke des Busses gesehen zu haben.

Ja, genau: das sollte das Ziel sein: vollständige Routen mappen.

Warum nicht darauf hinweisen, dass eventuell eine nicht vollständige Route vorliegt?

Klar. Sollte man möglichst machen.

Aber eine Zusatzregel zu PTv2, dass die erste und letzte Haltestelle bindend einen PTv2-Stop (oder gar gegen alle anderen PTv2-Regeln ein public_transport=stop_position) haben muss ist m. E. sinnlos. Entweder meint man nur die ersten und letzten Haltestellen der realen Linie … dann kann man nichts nachprüfen, da das nicht in der Route steht. Oder man meint die erste und letzte Haltestelle der erfassten Route, dann muss man ganz normale Haltestellen anders erfassen solange der Rest einer Route noch unbekannt ist und bei jeder dieser Änderungen alle anderen dort laufenden Routen anpassen. Praktikabel wäre so eine Regel nur, wenn es nur vollständige Routen in OSM gäbe.

Mmh, mein Ansatz ist eher:

  • eine erfasste Route, die nicht einer realen Route entspricht ist fehlerhaft.
  • eine erfasste Route, die nur teilweise einer realen Route entspricht ist unvollständig und somit auch fehlerhaft.

Bei dem konkreten Beispiel: “der erste Punkt des ersten Weges einer Route ist nicht die erste stop_position”

  • die erste stop_position ist in der Mitte des ersten Weges und der ist 5 Km lang - bei einem Bus irgendwie nicht passend.
    ** Der Weg sollte an der stop_position geteilt und der nicht relevante Teil entfernt werden.
    ** Wo keine Passagiere transportiert werden gehören die Wege nicht in die Relation.

  • die erste stop_position ist der Verbindungspunkt zwischen dem erstem und dem zweitem Weg
    ** Der erste Weg sollte aus der Relation entfernt werden (s.o.)

und so weiter, da gibt es viele verschiedene Aspekt.

Beide Beispiele können vollständig erfasste Routen sein, mit leichten Fehlern.
Beide Beispiele können aber auch unvollständige Routen sein, und vor dem ersten Weg fehlt noch was.

Beide Beispiele sind es in beiden Fällen wert gemeldet zu werden, meiner Meinung nach: es ist was zu tun (korrigieren versus erweitern).

Das sollte man dem Mapper nicht vorschlagen. Vielleicht fehlt nur eine Haltestelle davor und der Mapper teilt dann den Weg (erster Fehler) und löscht den völlig korrekten Teil aus der Relation (zweiter Fehler) und erweckt den Eindruck, die Route sei vollständig (dritter Fehler).

Wir sind uns aber völlig einig, dass da was gemeldet werden sollte.

Yep, das sollte vermieden werden. In solchen Fällen schaue ich mir ‘name’ und ‘from’ und ‘to’ an und entscheide dann vorsichtig anhand ‘name’ von erster und letzter Haltestelle.

Hi Toni,

hier hat sich ein Fehler eingeschlichen:

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=4.T0.19-564-s20-1.10.H

Gymnasium sium asium :smiley:

noch was:

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=26.T0.19-564-s20-1.15.R
https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?network=DE-BY-MVV&trip_id=7.T0.19-564-s20-1.13.R

die zwei sind gleich… bis auf Haltestelle 18. Trip “26.T0.19-564-s20-1.15.R” hat da einen Fehler :slight_smile:

… und nicht nur dort - nur dass es hier aufgefallen ist.

So war’s:

            $normalized =~ s/Gym./Gymnasium /g;
            $normalized =~ s/Gymn./Gymnasium /g;

So ist’s korrekt:

            $normalized =~ s/Gym\./Gymnasium /g;
            $normalized =~ s/Gymn\./Gymnasium /g;

:slight_smile:

Mmh, könnte man rausbekommen.

Die Analyse auf “unterschiedliche Trips” geht über die “stop_id” (die hier unterschiedlich sind) und nicht über den stop_name (identische Liste).

Das über “stop_name” zu machen würde auch bei vielen Zuglinien helfen, die an wechselnden Bahnsteigen halten und somit jedes mal eine eigene Variante darstellen.

Hier allerdings sind wohl die Inputdaten falsch (SISO = shit in, shit out). Oder auch GIGO = (garbage in, garbage out).

Ich werde es aber dennoch nicht über “stop_name” zusammenfassen, da ich nicht sicherstellen kann, dass ich als Referenz nicht zufällig die falsche trip-id erwische.

Aber: ich prüfe mal, ob ich für diesen Fall nicht doch eine “Warnung” generieren kann.