Busbahnhof mit meheren Bussteigen korrekt mappen

Ich beiße mir gerade am korrekten Mapping eines Busbahnhofs die Zähne aus. Hier die Relation dazu: https://www.openstreetmap.org/relation/8886391

  1. Wie nummeriert man die einzelnen Haltestellen richtig? Ich habe für die Plattformen und Stop Positionen die Beschriftung wie sie vor Ort zu finden ist als Name verwendet: “Bahnhof Bussteig 1” und zusätzlich local_ref=1. Der ref_name ist bei allen Haltestellen identisch, da in anderen Datenbanken nicht zwischen den Bussteigen unterschieden wird. Ist das richtig so?

  2. Zu jedem Bussteig habe ich die entsprechenden ref:IFOPT angegeben, die hier aufgeführt ist: http://diva4-9.efa-bw.de/Documents/Kataster/Kataster.8126.html
    Allerdings hat der Bahnhof 10 Bussteige und nicht 5 wie dort angegeben ist. Ich habe die IFOPT Nummern bis 10 ergänzt. Kann man das so machen, oder muss ich de:08126:10702:0:ohne für die restlichen Bussteige verwenden?

  3. Im Wiki ist angegeben, dass das in der Region verwendete Netzwerk der NVH ist. Das ist nicht richtig, 2005 wurde das Netz des NVH mit dem des HNV zusammengelegt. https://de.wikipedia.org/wiki/Heilbronner_Hohenloher_Haller_Nahverkehr
    Dementsprechend habe ich die Haltestellen mit network=HNV und operator=NVH getaggt, da der NVH weiterhin Betreiber der Haltestellen ist.
    Diese Kombination ist in der Region ohnehin verbreiteter als network=NVH. Kann ich das Wiki dementsprechend selbst abändern und die Tags auf der Karte aktualisieren, oder muss ich etwas beachten. Es sind sowieso nur wenige Bushaltestellen mit diesen Tags versehen.

  4. Ist es notwendig Tags auf Bussteigen zu verwenden, die identisch mit denen in der stop_area Relation sind, oder Erben die Elemente diese Information?

  5. Gibt es noch andere Fehler die ich mit dem Busbahnhof gemacht habe, an die ich hier nicht erwähnt habe?

Der Name muss für alle stop_positions und platforms derselbe sein wie in der stop_area.

Ob man das benutzen darf weiss ich nicht.

Besser keine IFOPT selbst erfinden.

Generell erben Elemente nichts. Es kann aber in der Beschreibung stehen, dass es doch so ist oder sich aus der Bedeutung ergeben. Z.B. steht in der Beschreibung von PTv2, dass der “name” in stops und platforms entfallen darf, wenn eine stop_area existiert (Sollte man aber besser drin lassen).

Ansonsten sieht es gut aus.

Bei den Routen müssen für jeden Halt zuerst die stop_position (sofern gemappt) und dann die platform (sofern gemappt) rein. Man muss nicht beide mappen, aber gemappte müssen rein. Insbesondere kommen keine Stations oder stop_areas rein.

Nurum: Geh mal davon aus, das das Meiste verebt wird.
Deine Erfindung der IFOPT …:ohne ist keine gute Lösung. Die Angabe im stop_area genügt. Du hast keine Information über die fehlenden IFOPT-Nummern am Haltepunkt, dann ist wohl auch der Bereich :0: geraten.

In der Handhabung ist es bei Busbahnhöfen einfacher, den Namen an der Platform nicht anzugeben. Nach public_transport-proposal sollte die Platform ein way oder area sein.

Weide: Warum drückst du dich so schwammig aus ? Hier werden nach ptv2 doppelte Haltestellen erzeugt.

Gruß, Axel

Ich finde es viel praktischer, bei beiden den Namen anzugeben.

Das stimmt nicht. Ein Node ist nach PTv2 völlig OK als Platform. Sogar wenn nur highway=bus_stop und kein public_transport=platform dran steht. Es steht ausdrücklich drin, dass ein Node mit highway=bus_stop neben der Fahrbahn eine Platform und auf der Fahrbahn eine stop_position ist.

Wo denn?

Meinst Du damit stop und platform? Dann ist es falsch: PTv2 verlangt nicht, dass beide angelegt werden. Aber es verlangt, dass die gemappten stops und platforms in die Routen kommen.

Ich habe das Tagging der Namen angepasst. Ich weiß gar nicht wo ich gelesen hatte, dass der Name des Bussteiges in den name-tag darf.

Die ref:IFOPT mit :Ohne am Ende habe nicht ich erfunden, sondern steht in der verlinkten Datenquelle. Das scheint in der Region bei Haltestellen mit mehreren Bussteigen gängige Praxis zu sein. Die Daten werden von der NVBW bereitgestellt und sollten durch deren Open Data Initiative für OSM verwendet werden können.

Ich habe die Plattformen als node getaggt, da die Plattformen fließend ineinander übergehen und Konsistenz mit den anderen in der Region vorhanden Bushaltestellen zu gewähren, die auch nur als node getaggt sind. Zudem kann der empfohlene lagacy tag highway=bus_stop nur auf Nodes gesetzt werden.

Wenn ich mir andere Städte anschaue, scheint die für mich gängigste Praxis zu sein, die Fläche der Bussteige wenn überhaupt zusätzlich als public_transport=platform mit dem lagacy tag highway=platform und bus=yes zu taggen. Im ist der Fall nicht explizit beschrieben aber ich schätze es schadet nicht lagacy tags zusätzlich zu taggen um die Daten auch für Anwendungen bereitzustellen die noch nicht PTv2 unterstützen. Selbst die Standard Karte kann noch nicht komplett mit PTv2 umgehen.

Die IFOPT-Nummer endet mit der Steigbezeichnung (Nummer oder Buchstabe). In den IFOPT-Listen sind teils auch Richtungsangaben dazugesetzt. Diese gehören nicht zur IFOPT. In deinem Falle ist also de:08126:10702:0 korrekt (de:08126:10702:0:1:ohne ist für mich grenzwertig, aber eindeutig).

highway=platform ist ein veralteter Tag, ein Versuch aus der Zeit vor ptv2. Das railway-Doppeltagging ist bei Straßen entbehrlich, da die Platform für Busse immer ein Teil des Fußweges oder der Verkehrsinsel ist.

Nachfrage meinerseits: in der Relation RegioBus 19: Künzelsau => Hohebach => Mergentheim ist jetzt an erster Stelle die o.g. Busbahnhof-Relation als “stop” enthalten. Genau das sollte doch aber nicht sein, wenn ich PTv2 richtig verstehe, oder? Nach meinem Verständnis müsste man anstatt der Busbahnhof-Relation den entsprechenden Bussteig an diesem Busbahnhof als “stop” (bzw. genau eher als “platform” und den eigentlich busstop in der Fahrbahn als “stop”) nehmen, oder?

Im stop_area fehlen noch die am die amenity soweit sie zum Busbahnhof gehören. Den Fahrradstellplatz und den 4-Plätze Parkplatz würde ich dazu setzen.

Harald Hartmann: Fast Richtig. Die Route scheint generell überarbeitungsbedürftig zu sein, aber natürlich gilt:
Rolle stop ist die public_transport=stop_position und
Rolle platform ist die public_transport=platform.
Das stop_area wird NICHT in die Route aufgenommen.

Ok, danke für die weitere Rückmeldung.
Das mit der Relation in der Route ist falsch. Ich habe das eingetragen bevor ich mich tiefer in die Routen eingelesen habe. Ich werde das noch abändern und die Routen nochmal kontrollieren, da sie doch recht antik sind. Danke für den Hinweis, das hätte ich übersehen.

Mit der Qualität der IFORT Daten in der Liste bin ich sowieso etwas unzufrieden, da teilweise Haltestellen aufgeführt werden die es nicht mehr gibt und andere fehlen. Genauso verhält es sich mit den Steigen an den Haltestellen. Ich lasse das :Ohne mal in den Tags, schreibe aber noch eine note dazu um das zu erklären.

@axelr Was meinst du mit railway-Doppeltagging? Ich stehe gerade etwas auf dem Schlauch.

Ja genau. Man muss allerdings nicht einen stop hinzufügen, wenn schon eine platform da ist oder eine platform hinzufügen, wenn schon ein stop da ist. Es ist auch nicht nötig, bei alten Tags wie highway=bus_stop oder railway=platform ein public_transport=… hinzuzufügen. (Es erleichert aber das Editieren mit JOSM auch wenn es am Informationsgehalt garnichts ändert.)

Wenn man aber weder den stop noch die platform kennt, dann ist ein Hinzufügen von “Irgendwas” besser als garnichts einzutragen. Dann kennt der nächste Mapper wenigstens schonmal die Stelle, an der repariert werden muss. Da könnte aber vielleicht die Rolle “fixme” besser geeignet sein als stop oder platform.

Bei ÖPV-Bahnhöfen werden die public_transport-tags und die railway-tags gesetzt.
Rolle stop mit public_transport=stop_position und railway=stop
Rolle platform mit public_transport=platform und railway=platform

Das liegt daran das das jüngere railwaymap-Konzept unabhängig von Güter- oder Personenverkehr immer die railway-tags verlangt. Bei den Platformen ist das auch sinnvoll, denn abgesehen von Western-Bahnhöfen sind diese um etwa 70cm erhöht und bilden ein besonderes Bauteil.

Sind hier angaben mit railway-tags überhaupt angebracht, da es sich um einen Bus-Bahnhof handelt. Der Bahnhof hatte bis 1991 noch eine Zuganbindung, von der heute nur noch ein Fahrradweg auf dem alten Gleisbett übrig ist.

Den Parkplatz habe ich der stop_area Relation hinzugefügt. Den Fahrradparkplatz nicht, da es sich um eine Art Hütte handelt, deren einzige geöffnete Seite vom Bahnhof weg zeigt und somit eher dem Fahrradweg zuzuordnen ist.

Die RegioBus 19 Relationen haben nun nicht mehr die stop_area als stop eingetragen, sondern die entsprechende Plattform. Aber die muss ich irgendwann noch reparieren und PTv2 konform machen.

Ein Problem ist da noch: “die entsprechende Platform” ist doppelt:

Wenn eine Platform gemappt ist, dass muss sie nach PTv2 in die Relationen der Buslinien, die dort halten. Deshalb kann man nicht sowohl eine Fläche oder Linie als Platform als auch einzelne Punkte darauf als Platform haben, denn dann müssten zwei Platforms zu einem Halt in die Route und das sind in PTv2 dann zwei Halte. Also gibt es zwei Möglichkeiten:

1.: Die Punkte behalten. Die drei Flächen werden Fußgängerbereiche ohne platform-tags und daher aus der stop_area entfernt.

2.: Die Flächen behalten. Dann brauchen sie den Namen und mehrere Steignummern und kommen in die Relationen. Die Platformnodes entfallen dann. Die stop-nodes bleiben. Da ein highway=bus_stop pro Halt vorhanden sein sollte und das Tag nur für Nodes geeignet ist, bekommen die stops jetzt das highway=bus_stop.

Dieses Problem habe ich gerade auch.
Es ist ein neuer Busbahnhof gebaut worden.
Ich habe das erstmal so gemappt : https://www.openstreetmap.org/#map=19/52.92134/9.23691

… Bushaltestellen auf den Wartebereich. ref. kommen noch später dran
… von dem nördlichen Knoten amenity=bus_station und public_transport=stop_position sollen dann die Relationen beginnen.

Kann man das so machen ? Für Tipps wäre ich dankbar.

@bison166: Mein erster Eindruck: Gruselig.

Die Straße als Multipolygon wurde in Eisenach https://forum.openstreetmap.org/viewtopic.php?id=62012 schon mal diskutiert. Die frustrierten Äußerungen und Hässlichkeiten gegen Mentz bitte überlesen. Die Fläche müßte wie https://www.openstreetmap.org/relation/8214790 als area:highway=service angelegt werden und ersetzt nicht den darüber gehenden way highway=service.

Vermutlich gibt es keine bauliche Trennung zwischen der Bahnhofstraße und den linken Bushalten. Hier gehören die stop_position auf die Bahnhofstraße und dein Multpolygon müsste mit der Bahnhofstraße verklebt werden. Ich vermute die Lage des Bussteigs dort, wo im Bing-Luftbild schwach eine Kontur zu erkennen ist.

service=parking_aisle ist ein innerer Parkplatzweg, diesen Tag löschen.

Die bus_stop’s gehören an die langen Abschnitte (wo der Bus andockt). Die vielen bus_stop’s sind nur notwendig, wenn noch viele ptv1-Routen existieren. Wenn es nur wenige ptv1-Routen sind würde ich die amenity=bus_station als dortigen stop einsetzen.

Die Insel mit derzeit highway=platform bekommt public_transport=platform.

Bei der rechten platform ist die Frage, ob Bahn-Bahnsteig und Bussteig offen sind oder z.B. durch einen Zaun oder Blumenkübel getrennt werden. In jedem Fall ist die Zickzack-Linie die Begrenzung eines area mit public_transport=platform für den Bus.

danke für deine Ausführungen.
Ich glaube, ich lass mal lieber die Finger davon.

Ihr merkt sicherlich, dass hier unterschiedliche Ansichten vertreten werden. Wer wissen will wer recht hat muss PTv2 durchlesen:
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

@bison166:

Ich würde da keine weiteren Flächen hinzufügen und die Haltestellennodes so lassen. Die Mittelfläche sollte highway=pedestrian und area=yes bekommen und die beiden platform-Tags verlieren. Beim Bus-station-node würde ich das public_transport=stop_position rausnehmen. In die Routen kann dann immer einer der Haltestellennodes mit der Rolle “platform” eingetragen werden. Stopeinträge brauchen wir da nicht, wenn man keine gemappt hat.

Bei PTv1-Routen ist es etwas ander: sie kennen aber keine Rolle “platform”. Als Haltestellen trägt man bei denen immer nur den Node mit highway=bus_stop und der Rolle “stop” ein. Die Rolle kann man da aber auch weglassen, denn Haltestellen werden bei PTv1 daran erkannt, dass sie Nodes sind. Alles linienförmige ist bei PTv1 Fahrweg. Flächen und Relationen kommen da garnicht vor.

Den Link würde ich erst mal micht als Maß aller Dinge ansehen. Das ist noch im Proposal-Stadium und

Ich denke, das Problem mit den Straßen als Areas sollte anders gelöst werden. Wie? Muss man sich mal Gedanken drüber machen.

Da hier der Eisenacher ZOB ins Gespräch gebracht wurde. Da haben Leute, die nie dort gewesen sind, mutmaßlich mit nicht OSM konformen Quellen, was “hingezaubert” was nicht die “on the ground” Realität ist.

Zwischen den überdachten Bussteigen sind große Straßenflächen, wo ohne Probleme 4 Busse nebeneinander passen. In der Realiät ist es so, dass die Bussteige entsprechend ihrer Anlage jeweils wie eine Einbahnstraße bedient werden und das jeweils gegenläufig. In der Mitte fahren auch mal Busse durch oder werden kurz mal zwischen geparkt. Das heißt die** Fläche** zwischen den Bussteigen wird schon wie eine Straße genutzt. Deshalb würde es Sinn machen, die Straßen als Area zu taggen, nur wie, das muss man sich halt noch mal überlegen.

Das ganze PTV2-Schema ist ziemlich kompliziert. Ich habe mal versucht, die Buslinien vom alten Busbahnhof zum neuen Busbahnhof zu schwenken. Als ich mich dann tiefer in die Materie eingearbeitet hatte, habe ich es aufgegeben, weil dort einige Linienführungen, die ich überprüft habe, nicht mehr aktuell waren (Haltestellen verlegt etc) und an den Routen mittlerweile soviel kaputt ist, das eigentlich nur noch eine Löschung und Neuauflage Sinn macht. Wenn man das nach PTV2 versucht, ist das fast ein Tagwerk. Das kann ich dann auch nicht mehr leisten. Zumal diese Routen hauptsächlich für kommerzielle Programme genutzt werden.

Das Ding ist im Endstadium: fertig abgestimmt und beschlossen.

Nach der Abstimmung wurde der Abstimmungstext verändert. Es gab dann einen kleinen Editwar und als “Kompromiss” steht da jetzt dran, dass der tatsächlich beschlossene Text nur als Archivfassung vorliegt.

Es gibt m.W. weder kommerzielle noch andere Programme, die unsere Routen nutzen. Die kommerziellen benutzen alle nur unsere Karten als Hintergrund und unsere Fußwege für das Fußgängerrouting beim Umsteigen. Das liegt daran, dass der tatsächliche Zustand der Routen und Wikis nicht PTv2 entspricht. PTv2 hat zwar erhebliche Schwächen … aber wenn es nicht jeder nach eigenem Geschmack verändern würde, dann könnten Apps darauf basieren und in manchen Fällen sogar den jetzigen überlegen sein.

Deshalb bin ich dafür, PTv2 genau so zu lassen wie es beschlossen wurde und an einem PTv3 zu arbeiten, dass die in PTv2 wirklich existierenden Probleme anpackt.

Da kann man durchaus geteilter Meinung sein. Es gibt die Firma Mentz, die teilweise die Daten verschlimmbessern; weniger bei Busbahnhöfen mehr im Bereich des schienengebundenen Verkehrs. Dort werden auch Änderungen für Router vorgenommen, wo ich kein Freund von bin (siehe meine Mantras :slight_smile: ).

Zu PTV2 kann ich Dir nur zustimmen.

Aber:
Ich gbe zu bedenken, dass wir hier halt ein sehr offenes Projekt mit vielen Freiheiten sind, die ich auch nicht missen möchte. Deshalb wäre mein Interesse das PTV3 so zu verbessern, dass es von den Mappern auch angenommen / angewendet wird. Das bedeutet auch es zu vereinfachen.