Komplizierte Bus-Relationen, Bitte um Überprüfung

Moie, liebe Mit-Mapper :raising_hand_man:!

In Wetzlar verfolge ich einen Hinweis, dem ich schon länger aus dem Weg gehe, weil er mir doch sehr kompliziert erschien (mußte erstmal Erfahrungen sammeln). Nun habe ich mich mal dran gewagt und bin prompt auf ein für mich (noch) unverständliches Problem gestoßen. Zwar war die im Hinweis erwähnte “keine Einbahnstraße für Busse” bereits als bus=opposite eingetragen, die Relationen sind aber noch zu übertragen.

Habe also angefangen, diese von hier und hier in die erwähnte Einbahnstraße zu verlegen. Bin fast fertig, habe aber jetzt erstmal die Bearbeitung gestoppt und will Euch fragen (bevor ich was zerschieße), warum sind dort die Buslinien 120/125 und 185 jeweils zweifach als Relation erfaßt? Ist das wirklich so richtig, oder kann je eine weg? :thinking: Fällt Euch sonst nochwas auf, das ich beachten sollte?

Der Linienplan hilft mir leider in seiner geringen Übersichtlichkeit nicht weiter.

Bevor ich also meine Bearbeitung hochlade, will ich lieber mal gefragt haben…

Besten Dank für alle Hinweise und Erklärungen :exclamation:

(ich mach erstmal Pause :tv: + :beer:)

1 Like

Das ist ok, manchmal sind es sogar mehr. Für jede Variante, Richtung gibt es jeweils eine eigene Relation.

MMn ist oneway:bus=no der passendere Tag. opposite kenne ich eigentlich nur von cycleway und auch da wird mittlerweile auch oneway:bicycle=no verwendet.

In Wetzlar gibt es ein Mix aus public_transport:version=2 und public_transport:version=1 Relationen. Je nach Schema gibt es unterschiedliche Tagging-Richtlinien. Bus 185 und Bus 120/125 sind public_transport:version=1 und ich finde jeweils nur eine Relation, allerdings sind die Straßen doppelt als Mitglieder in den Relationen erfasst, was nach meinem Verständnis falsch ist. Jedoch sieht es so aus, als ob dies systematisch gemacht wurde.

Nebenbei bemerkt: Sind das wirklich drei Haltestellen “Seibertstraße” auf der gleichen Straßenseite hintereinander?

So, nochmal reingekniet - und aufgesteckt :crazy_face:: Das mit dem Mix von PTv1 und PTv2 ist mir einfach zu hoch und die Gefahr, was kaputt zu machen, ist gerade mit iD zu groß. Da hilft mir leider auch nicht die tolle PTNA von Dir, @ToniE

Also besser Finger weg von der Herdplatte :fire: und zurück in den Sandkasten :beach_umbrella: !

Habe jetzt nur

eingebaut - und den Rest in die Tonne gegeben.

Was die 3-fache Bushaltestelle betrifft:

Die erinnert mich an unseren Busbahnhof in Herborn. Da vermute ich, es wäre besser 3 Haltepunkte (mit den entsprechenden Relationen) auf die Straße zu kleben und nur 1 Bushaltestelle (mit dann allen Relationen) zu behalten, aber auch das übersteigt meine derzeitigen Fähigkeiten.

Von daher vielen Dank an Euch, habe wieder viel gelernt (keine Arbeit in OSM vergeblich!), aber ich bleib’ besser bei den mir vertrauten Möglichkeiten und der Hinweis weiterhin unerledigt, aber wer weiß, wo ich mich später mal noch hin entwickel :interrobang:

2 Likes

Was mir beim 185er aufgefallen war: ‘operator’ ist nicht gesetzt.
Daher kann PTNA nicht zwischen diesem und anderen 185er in anderen RMV-Gegenden unterscheiden.

OT:
Hallo Andreas, jetzt muss ich Dir ja mal verschärfte Anerkennung aussprechen (BW Jargon 70er Jahre :grinning:), zum einen, dass Du Dich an die ÖPNV Relationen ran gearbeitet hast und zum zweiten, dass Du Dir selber eingestehst, dass das Thema aktuell noch eine Nummer zu groß ist. Respekt!

Ich bin ja jetzt schon ein paar Jahre dabei und habe bisher immer einen grroßen Bogen um die Routen gemacht. Haltestellen und Haltepunkte mappen und Tags ergänzen ja, ÖPNV-Route anlegen never ever. Wobei ich denke, dass man mit iD da weniger kaputt machen kann als mit JOSM, weil das letztere einfach wesentlich wirkmächtigere Tools beinhaltet. Aber alleine den Nerv, sich in das Thema mit PTv1 und PTv2 einzulesen, muss man erst mal haben.

Ich bin mir sicher, Du wirst das nicht aufgeben, und in einem Jahr hast Du das im Griff und dann kannst Du hier in HEF-ROF alle PT-Relationen anlegen, da gibt es bisher noch überhaupt keine. Ich kümmere mich derweil um Waldwege und die Differenzierung zwischen gravel, crushed stone und pebbles … :wink:

1 Like

Bei PTv1 ist die Gefahr eigentlich niedriger als bei v2, aber ohne Ortskenntnisse habe ich mich auch nicht an Bus 10, Bus 120/125 und Bus 185 getraut. Die restlichen Linien sollten jetzt an der Kreuzung stimmen:

Ja, so würde ich es auch machen, wenn das eine Steig ist und nicht etwa drei mit jeweils eigener ref:IFOPT. Allerdings ist das mit PTv1 kompliziert, da ja nur die Steige und nicht die Haltepunkte in die Relation gehören. Witziger weise ist die nördlichste Haltestelle in keiner Relation als Mitglied.

Als jemand, der mehrere Buslinien in Mainz und Mainz-Bingen ergänzt hat (sei es neue Linien), muss ich sagen, dass es nicht so schwierig ist, sondern lediglich aufwändig, da man mit so vielen Elementen arbeiten muss.

Allerdings muss man auch sagen, dass iD wirklich nicht für weitflächigen Routen gedacht ist (ich spreche aus Erfahrung) und nach einigen Problemen davon ich zu JOSM gewechselt habe. Der größte Vorteil von JOSM ist, dass Relation ihre eigene Fenster haben und man so diese immer zur Hand hat im Gegensatz zu iD und noch weitere QoL-Funktionen hat, wie dass man sehen kann, ob eine Linie eine Lücke hat oder nicht.

Allerdings muss ich auch sagen, dass man i.d.R. selber die Route kennen muss, um eine PTv1- in eine PTv2-Route zu aktualisieren, dank den vielen möglichen Abzweigen, die eine PTv1-Route hat (manchmal ist es auch einfacher, die Relationen komplett von Neu anzufangen). Die einzigen, die ich gemacht habe, waren entweder liniar (d.h. sie hatte keine Abzweigungen und machte sonst so keine merkwürdige Kurven) oder waren ein Hybrid d.h. die Linie hat separate Hin- und Gegenrichtungen.