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…
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.
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.
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.
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 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 dann muss ich nicht so zählen um die Gesamtzahl zu ermitteln
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
dann muss ich nicht so zählen um die Gesamtzahl zu ermitteln