Wie schon länger angekündigt, möchte ich die Wikiseite zum Aachener Verkehrsverbung überarbeiten. Ein erster Entwurf der einleitung und erläuterungen zum Tagging sind jetzt in einem frühen Entwurf hier zu finden: https://wiki.openstreetmap.org/wiki/User:Trockennasenaffe/DE:Aachener_Verkehrsverbund. Ich bitte um Korrekturen, Ergänzungen und Verbesserungsvorschläge. Wäre insbesondere gut, wenn die Experten prüfen könnten, ob alles Sachlich korrekt ist.
Die Platform-Nodes machen nur Probleme, es ist besser, die Platform als way vorzugeben und node als Notlösung anzusehen.
Verschärft wird dieses Problem, wenn der Platform-Node zusätzlich ein highway=bus_stop bekommt, da damit in der Regel doppelte Haltestelle erzeugt werden.
Der Wartebereich wird mit public_transport=platform markiert und ist nicht routingfähig. Die Verkehrsinsel im Busbahnhof ist der sidewalk der entsprechenden Busspur, der sidewalk ist routingfähig.
local_ref wird nach meinem Kenntnisstand nur für die Londoner Bushaltestellen mit 2-Buchstaben-Bezeichnung ausgewertet. Man kann sich dies zunutze machen, um auf der transport-Karte die Steignummer am bus_stop anzuzeigen. Bei Bussteigen mit römischen Zahlen versagt dieses System.
Für mich ist es nicht sinnvoll diese Insellösung zum Standard zu erheben. Public_transport sieht ref= vor.
Das Ding mit den 4 Rädern auf der Straße ist ein Bus und kein AVV. Insofern sollte direkt Bus 123 als Name empfohlen werden.
Zur Namensgebung AVV wäre es sinnvoll sich mit Augsburg abzusprechen. Die Linienauswertung per network= und ref= ist einfacher in der Handhabung als die Hinzunahme von Ortsbezug oder Betreiber.
Die Restriktion bei Betriebsstellen verstehe ich nicht. Wenn man sich zu ptv2 bekennt, sollte man es auch anwenden.
Gruß Axel
Das höre ich in der Zeit in der ich mich mit öffentlichem Verkehr beschäftige zum ersten mal. Immerhin sind geschätzt ca. 90% der Bushaltestellen auf AVV Gebiet so gemappt und das seit etlichen Jahren, ohne das dies jemand bemängelt hätte. Kannst du das näher erläutern?
Was meinst du mit “die Platform als way vorzugeben”? Warum es meistens sinnlos ist Platformen als Linie neben die Straße zu setzen
wo sie nicht mit dem Wegenetz verbunden sind, wurde hier http://forum.openstreetmap.org/viewtopic.php?id=53809 schon diskutiert. Nodes entsprechen meines Erachtens meist viel eher den real existierenden Gegebenheiten: Es gibt einen Haltestellenmast und da will ich als Fahrgast hin.
Klar, highway=bus_stop darf maximal einmal pro Haltestelle vorkommen. Da habe ich auf der Seite daher ja auch ausdrücklich darauf hingewiesen. Meines Erachtens ist highway=bus_stop aber ohnehin verzichtbar und nur noch aus Kompatibilitätsgründen berechtigt. Eine stop_position mit bus=yes und public_transport=platform mit bus=yes ist einheitlicher und weniger fehleranfällig,
Das stimmt so prinzipiell nicht. Wenn es sich z.B um einen Bahnsteig handelt muss der natürlich routingfähig sein.
Wie zeichnet man denn den sidewalk eines Weges einseitig als Platform aus und weist im eigenschaften zu? Kannst du ein real existierendes Beispiel zeigen? Sind sidewaks die im Nichts beginnen und im Nichts enden wirklich routingfäghig?
So wird es momentan im AVV gemacht. Es ist nicht meine Entscheidung. Wenn man statt local_ref ref nehmen soll, habe ich nichts dagegen das zu migrieren, aber wie?
Nochmal: So wurde es bisher bei allen existierenden Buslinien im AVV gemacht. Ich weis dass das nicht korrekt ist, und wenn du dich imstande siehst die von jetzt auf gleich umzustellen halte ich dich nicht davon ab. Bis dahin ziehe ich eine einheitliche Vorgehensweise vor.
Bei meiner Stichprobenartigen Begutachtung des Augsburger ÖPNV in OSM habe ich festgestellt, das dieser nur rudimentär gemappt ist. Eine Verwendung von “network” konnte ich nicht entdecken. Ansprechpartner oder Dokumentation habe ich auch keine gefunden. Daher wüsste ich nicht, wie man hier etwas absprechen soll. Bin für Vorschläge offen.
Da stimme ich zu. Im AVV wir halt traditionell network=AVV verwendet und das lässt sich wohl nur mit viel Aufwand ändern, auch wenn mir “Aachener Verkehrsverbund” lieber wäre. “network=AVV” scheint aber momentan (noch) eindeutig zu sein.
Die openrailwaymap besteht darauf, dass sich railway=facility mit puplic_transport=stop_area die Relation teilt. Eine Entscheidung, die möglicherweise zweifelhaft ist, da es sich doch um zwei recht unterschiedliche Dinge handelt (Wäre gut wenn da jemand von der openrailwaymap mal stellung beziehen könnte). railway=facility ist dabei sehr viel restriktiver, was in so eine Relation rein darf, daher sind nicht alle puplic_transport=stop_area auch gültige ailway=facility. Man kann aber Relationen erstellen, die beiden Anforderungen genügen und das war der Weg, den ich gehen wollte und der auch in der Praxis in der regel angewandt wurde.
zu Platform-Nodes:
Nimm mal als Beispiel ref 90371 Bus 77 oder http://www.overpass-api.de/api/sketch-line?network=AVV&ref=77&style=padua
Wenn 90% der Plattformen als nodes gemapped sind spiegelt die Linie das Problem, 90% der Haltestellen sind doppelte Haltestellen.
zu public_transport=platform:
Der Wartebereich ist nicht routingfähig. Eine Verkehrsinsel, ein Fußweg oder ein sidewalk schon. Es gab für Verkehrsinseln mal einen Ansatz, den ich im Moment nicht finde. Du mußt dich aber grundsätzlich von dem Gedanken lösen, es seien nur Punkte erreichbar, die durch eine Linie angebunden sind. Der Referenzpunkt eines Wartbereiches ist der Fußpunkt eines Lotes der stop_position auf die Platform (Beim Platform-Node also immer der Punkt selber).
Ein Fußweg ist in voller Breite begehbar auch wenn die Breite meist nicht benannt ist. Und der gesamte Bereich ist erreichbar.
Das Problem liegt nur daran, dass diese Auswertung offensichtlich kein Public-Transport Version 2 versteht und mit der Rolle “Platform” nichts anfangen kann. Sichtbar ist das z.B. an der Haltestelle "Laurensberg, die völlig korrekt nach PTv2 hinzugefügt wurde. Die Relation hat aber trotzdem Fehler, die aber hiermit nichts zu tun haben. Ich schaue mir das mal an.
Hab mich der Linienrelationen für die 77 mal angenommen. Die sind jetzt völlig korrekt bis auf die Sache das eine Relation den Bushof zweimal enthält. Das liegt daran, das der Bus dort je nach Tageszeit an einer anderen Haltestelle hält. Hier müsste man korrekterweise zwei raltionen draus machen, aber habe ich momentan keinen Bock drauf, das zu erledigen. Deine Darstellung produziert einfach Müll, da sie wie bereits gesagt, nicht mit Ptv2 klar kommt…
Es ist weder meine Darstellung noch produziert sie Müll.
Schau dir mal ein Beispiel aus der Umgebung an. Da sind platform-nodes und platform-ways drin.
rel 1734067 http://www.overpass-api.de/api/sketch-line?network=VRR&ref=36&style=padua
Gruß Axel
Die Linienrelation für die AVV-Linie 77 ist definitiv gültiges Ptv2. Die platform-ways aus deinem Beispiel haben hingegen kein highway=platform oder sonst etwas, dass sie als Bushaltestelle kennzeichnen würde. Daher werden sie wohl von der Darstellung, die kein Ptv2 unterstützt ignoriert. Ich werde das mal testen.
Wie her auch schon in einer anderen Thread besprochen, behauptet die overpass-api zwar, PTv2 zu können, die Implementierung ist aber offensichtlich stark fehlerhaft. Daher kommen offenbar die Probleme.
Leider scheint das hier etwas im Sand zu verlaufen was echt schade wäre. Rückmeldungen halten sich leider stark in Grenzen. Ich bin unschlüssig, wie ich weiter vorgehen soll.
Da das Interesse hier offenbar nahe Null ist, stehe ich jetzt vor der Entscheidung, das Schweigen als Zustimmung zu werten und das einfach im Alleingang durchzuziehen wie ich mir das vorstelle und bisher skizziert habe oder es einfach sein zu lassen und die bisherige Arbeit einzustampfen. Ich denke ich gebe jedem noch mal ein paar Tage sich zu außern und werde dann entscheiden, ob ich darauf überhaupt noch Bock habe oder nicht.
Ich spreche sicher auch für zwei oder drei andere, wenn ich sage, daß mein Schweigen zu diesem Thema schlicht daran liegt, daß ich mich mit PT-Mapping noch praktisch überhaupt nicht beschäftigt habe.
Das heißt also nicht „smirdochscheißegal“, sondern „sorry, nicht meine Baustelle, kann ich nix zu sagen“.
–ks
+1. Geht mir (leider) genauso, und sicher noch vielen anderen ebenso …
+1 mir auch. Ich mappe kein PT. Nicht mein Spezialgebiet.
Dito. Also zieh es ruhig durch.
Gruss
walter
Auch bei OSM ist “BOLD, revert, discuss” anwendbar: https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle
Warum nur Haltestellen vom gleichen Verkehrstyp in stop_area?
Die Abgrenzung von stop_area zu stop:area_group soll damit präzisiert werden. Im AVV besteht ohnehin nur der Fall des Bahnhofs mit angeschlossener Bushaltestelle. Da gibt es das Problem, dass die stop-area des Bahnhofs auch eine railway=facility sein sollte die aber nicht die Bushaltestelle mit umfasst. In der Praxis haben die ohnehin meist unterschiedliche Namen wie “Westbahnhof” vs “Aachen West” Ich werde das aber wohl noch etwas überarbeiten.
Stop_area_group gibt es zumindest nicht offiziell - und auf deiner Seite ist es bis jetzt nicht erwähnt. Aber die Fälle sind bei dir selten (hier in Stuttgart wegen Stadtbahn und Bus öfter) und man braucht darüber nicht groß streiten.
OpenStreetMap ist eben eine “Do-ocracy”. Natürlich diskutiert man und hört sich die Meinung der Community an, aber letztlich entscheidet der, der die Arbeit macht, wie es gemacht wird. Manchmal muss man einfach auch selbst die Initiative ergreifen und mit einem Vorschlag vorpreschen. Viele User haben keine schlicht Lust, sich an der Ausarbeitung von Taggingschemata zu beteiligen. Sie wollen einfach nur nach irgendeinem Schema mappen, das jemand vorgegeben hat.
Wenn keine Reaktionen kommen, würde ich das als stille Zustimmung nach dem Motto “ja mach doch einfach” deuten. Jeder Mapper hat so seine Schwerpunkte. Wie man hört, sind es beim ÖPNV relativ wenige Leute. Von den Leuten, die sich eh nicht für das Thema interessieren, wirst du sowieso keine Reaktionen bekommen, außer wenn es grober Unfug sein sollte. Und von den ÖPNV-Mappern dürfte auch nur eine Reaktion kommen, wenn sie etwas zu kritisieren haben. An den Views sieht man ja, dass deutlich mehr Leute sich deinen Vorschlag angesehen haben dürften, als sich letztlich auch zu Wort gemeldet haben. Viele werden wohl deinen Vorschlag überflogen haben, haben nichts problematisches gefunden und sich dann auch nicht weiter mit der Diskussion beschäftigt.
Als ÖPNV-Mapper habe ich mir nochmal deinen Entwurf angesehen und habe den Eindruck, dass er bis auf ein paar Kleinigkeiten nur nochmal eine kurze Wiederholung des PTv2-Schemas ist. Daher kann ich auch verstehen, dass die Sache eingeschlafen ist, weil es da nicht mehr viel zu diskutieren gibt und das Tagging in dieser Form schon länger dokumentiert und angewendet wird. Die einzigen strittigen Punkte hier waren irgendwelche Detailfragen wie “Abkürzung oder ausgeschriebener Betreiber”. Das sind aber Fragen, bei denen man noch ewig weiterdiskutieren könnte, ohne zu einem Konsens zu kommen. Solche Geschmacksfragen liegen in der Freiheit des Mappers und setzen sich im Zweifel durch die Unterstützung einer bestimmten Variante durch Anwendungen durchsetzen. Hier musst du nicht auf eine Zustimmung durch irgendwen warten, sondern kannst einfach das taggen, was du für richtig hältst.
Da dein Entwurf nach meinem Eindruck weitgehend deckungsgleich mit dem PTv2-Schema ist, stellt sich die Frage, ob es überhaupt sinnvoll ist, diese Seite zu pflegen. Das gleiche Schema an etlichen Stellen im Wiki zu dokumentieren, ist schlicht redundant und macht die Pflege der Dokumentation komplizierter. Ich würde auf der Wikiseite zu einem Verkehrsverbund nur spezifische Besonderheiten beim Anwenden des PTv2-Schemas in diesem Verkehrsverbund dokumentieren, aber nicht nochmal das gesamte Tagging aufführen. Das Ziel ist ja eigentlich, dass möglichst der weltweite ÖPNV in einem einheitlichen Schema erfasst wird. Wenn aber für jeden Verkehrsverbund eine eigene Taggingseite erstellt wird, besteht die Gefahr, dass da mit der Zeit die “Synchronisierung” verloren geht und letztlich jeder Verkehrsverbund ein leicht anderes Schema verwendet.
Gruß
Alex