PTNA - News: GTFS-Analyse

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.

Warnung würde auch schon genügen… meine odt-Tabelle hat gleich gemeckert… “doppelt”… bei genauerem hinschauen hab ich es halt auf der Map gesehen wo die Anweichung ist. Dazu ist die Map perfekt :slight_smile: wenn man zwischen die Tabs hin und herwechselt

Ich werde das so machen: bei gleicher Anzahl von Stops ermittle ich die stop_names und bei identischen stop_names suche ich nach dem/den “Übeltäter(n)” wieder anhand von stop_id.

ähh was ich mich schon mal gedacht hab. Kann man die Spalte “Linie” durch “Variante”/“Nr.” 1, 2, 3, 4, 5… usw. ersetzen… fände ich nützlicher :wink: dann muss ich nicht so zählen um die Gesamtzahl zu ermitteln :slight_smile:

Also auf der Trip Seite: z.B.
https://ptna.openstreetmap.de/gtfs/DE/trips.php?network=DE-BY-MVV&route_id=19-210-s20-1

Da rennst du offene Türen ein.

BTW: es gibt nicht nur Trips mit “eigenartigem” Ende.

Beim VBB (Tram?) habe ich welche gefunden, die am Anfang und am Ende eigenartig sind: jeweils zwei mit selbem Namen, selber Position aber anderer Stop-ID

Habe die Analyse der GTFS-Daten erweitert:

  • Prüfung, ob die erste und zweite Haltestelle den selben Namen haben
    ** für vorletzte und letzte Haltestelle ist’s ja schon realisiert

  • Prüfung, ob zwei Trips (Fahrten/Varianten) bzgl. Haltestellennamen die selbe Strecke fahren (s.o.)
    ** … aber unterschiedliche Stop-IDs (Platforms) anfahren
    *** Für MVV:
    **** Busse 240, 413, 444, 447, 531, 564, 619, 785 (22 Trips = 11 Paare)

Für MVV ist es gemacht. Für andere auf Anfrage, bzw. beim nächsten Update der GTFS-Daten.

Ja cool :sunglasses:, macht es wieder ein Stück einfacher :slight_smile:

So ich bin durch :slight_smile: LK Ebersberg gefixt und update… und LK Erding auch alle Varianten drin :sunglasses: ab Bus 540 fehlt immer wieder das “Shape” … deswegen sind auch die Ptv1 Relationen am Leben geblieben… die kann man ja rendern :wink: 600 Freising usw. - 900 darf wer anders machen :confused:

Aber die Analyse macht es schon erheblich einfach :slight_smile: :slight_smile:

Gruß Miche

PS: den Busbahnhof in Erding, Klinik muss ich mir mal genauer anschauen vor Ort… da muss so einiges nicht stimmen :confused:

Stimmt, ich habe auch mal wieder angefangen 2xxer zu kontrollieren. Geht schneller und systematischer, wenn man z.B. bei beiden (OSM, GTFS) die Liste der Haltestellen und gegebenenfalls als dritte Liste den PDF-Fahrplan vergleicht.

Ich war letztes Jahr mal dort zum Mappen, aber leider hat’s geregnet- schlechte Voraussetzungen um von Pole zu Pole zu marschieren und zu schauen, welcher Bus wo abfährt.

Ja bei “Klinik Nord” angesichts dessen das die Bustür ja rechts ist muss der Bus ja bei paar Platformen von der Gegenrichtung anfahren :confused: Das glaub ich hab selbst mal falsch aufgefasst :roll_eyes: Desweitern ist da noch schwierig ob dann ein Bus die Platform link oder rechts anfährt… die Schilder stehen mittig auf der Platform. Eventuell wird auch entgegen gehalten wenn die Platform von der einen Seite gerade belegt ist :confused: