Ich habe da mal eine Frage zum ÖPNV Tagging Schema…das neue da. Gegeben sei eine Bushaltestelle… beidseitig. Also wenn ich das richtig verstanden habe, mache ich das so:
2x Haltestellenschild/Fahrplan/Bank/etc (inkl highway=bus_stop + public_transport=platform neben und public_transport=stop_position auf der Straße) in zwei verschiedene type=public_transport/ public_transport=stop_area Relation (eine je Straßenseite)
beide Relation kommen in eine type=site, site=bus_stop Relation
diese kommt in die beiden(Hin- + Rückweg) Routen-Relationen
diese kommen in die Route-Master Relation.
Das erscheint mir ein bissl heftig und ich bin gespannt, was Hurdygurdyman dazu sagt ;-). Bei 10 Haltestellen auf einer Strecke bastelt man 33 Relationen
Aber gut, wenn sein muss.
Jetzt stehen Haltstellen für Hin- und Rückweg manchmal 100m auseinander. Die heissen genauso und lt. dem Schema kommen sie in eine Site-Relation. Woher weiß der Router jetzt, wo der Bus hält? In der Route ist ja die Site-Relation. Und in der Site Relation sind zwei stop_area Relationen, die jeweils eine stop_position haben. Für uns Menschen ist das easy…einfach die, wo das Haltestellenschild rechts in Fahrrichtung ist. Aber das ist nicht überall so und bestimmt schwer zu programmieren.
Du zeichnest normalerweise eine stop_position auf der Straße. Dort, wo der Bus auf der jeweiligen Straßenseite hält wird eine platform eingezeichnet. Diese liegt nicht auf der Straße als Weg. Alle Objekte, die Haltestelle gehören kommen ein EINE stop_area Relation. Die Relation kommt nicht in die route_master-Relation, sondern die stop_position.
Dein im letzten Absatz beschriebenes Beispiel ist ein Sonderfall, 100 Meter wären weit. In diesem Fall könnte man 2 stop_positions einzeichnen (diese kommen aber auch in dieselbe stop_area Relation) einzeichnen. Ich halte es allerdings für einfacher, nur eine stop_position zu verwenden.
so meinte ich das auch. War vielleicht nicht ganz klar beschrieben.
So dachte ich bisher auch, aber das Argument, dass man bei unterschiedlich ausgestatteten “platforms” in einer stop_area Relation dann nicht weiß, ob nun die Sitzbank, Häuschen, Blindenknopf etc zu welcher Platform gehört, klingt logisch. Das kommt ja auch in die stop_area Relation.
Du brauchst je Richtung eine Routen-Relation. Darin sind enthalten:
Alle Wege dieser Route ohne Rolle (sinnvollerweise sortiert)
Alle Plattformen auf dieser Route (also einseitig) mit der Rolle platform
Auch die Plattformen sollten in Fahrtrichtung sortiert sein.
Das muss man leider per Hand machen.
Soweit vorhanden die zugehörigen Stoppstellen mit der Rolle stop
Die sollen vor/hinter der zugehörigen Plattform stehen (müsstes du noch nachsehen)
Mehr braucht es nicht.
Insbesondere kommt keine Haltestellen-Relation in die Routen-Relation.
Eine Haltestellen-Relation braucht es für die Route nicht. Sie ist aber nützlich, wenn Haltestellen gleichen Namens etwas auseinander liegen (z.B. über eine Kreuzung / eine Ecke verteilt), um die Zusammengehörigkeit zu dokumentieren. Wenn man eine Haltestellen-Relation erstellt, gehören alle Plattformen gleichen Namens und die zugehörigen Stoppstellen
in diese Relation. Also insbesondere beide Richtungshaltestellen.
Wie gesagt braucht man die Haltestellen-Relation nicht für die Routen-Relation, da dabei nicht klar wäre, welche Plattform/Stoppstelle eigentlich gemeint ist. Sie ist aber nützlich um zusammengehörende Haltestellen wie z.B. auf der ÖPNV-Karte darzustellen.
Für Haltestellen-Relationen verwendet man type=public_transport und public_transport=stop_area als Taggs der Relation plus Name, Network, Betreiber usw. soweit man das eben weis.
Woher die Idee mit der Site-Relation kommt, weis ich nicht, im Public_Transport Proposal, findert sie sich jedenfalls nicht. Die würde ich also einfach ignorieren.
Falls es dir für den Anfang zuviele Relationen sind, kanst du vorerst die Haltestellen-Relationen weglassen. Die Plattformen und ggfs. Stoppstellen sind ja einzeln in der Routen-Relation aufgeführt.
Ausstattungen wie Bänke, Wartehäuschen, Ticket-Automat, … wird an den Plattformen vermerkt und nicht in der stop_area Relation. Dort wäre eine Zuordnung in der Tat nicht möglich.
Ich sag da gar nix zu Nicht meine Baustelle
OT?:
Wenn allerdings “site” als relation verwendet werden soll, müsste die Wiki hier http://wiki.openstreetmap.org/wiki/Relations
(auch die deutsche) geängert werden, denn da steht was von Gebäuden, während hier http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
alles mögliche zusammengefasst werden kann.
Der proposal-Prozess ist zwar noch nicht abgeschlossen, aber …
…wer hilft wambachers avatar endlich beim Wiki putzen?
Ja das ist eine Aufzählung von Alternativen, wobei die unified_stoparea den Nachteil hat, nichts zu den Fahrt-Wegen zu sagen.
Die Aussage, dass das Public Transport Schema auf unified_stoparea aufbaut ist sachlich falsch, da auf der Proposal Seite die unified_stoparea nur unter “See also” erwähnt wird. Real baut sie bei der Haltestellen-Definition auf dem Oxoma Schemas auf.
Totale Verwirrung eben. Nicht umsonst ist der Bereich Public Transport mit 19 Haupt- und 19 Unterpunkten eines der größten Clean-Up Projekte im Wiki.
Sieht soweit gut aus. Wege und Haltestellen sind in einer Reihenfolge.
Lediglich die Rolle für die stop_positions ist einfach stop. (Dann meckert auch JOSM nicht mehr)
Die Weg hinter die Haltestellen anzuordnen erscheint mir widersinnig und ich ignoriere das für meinen Teil. Aber es ist so im Proposal festgelegt, von daher ist das in Ordnung.
Am ZOB muss noch einiges in Ordnung gebracht werden. Das hast du ja beim Wegstück dort selber gesehen. Aber immer eines nach dem anderen. Der Bus darf dort gegen die Einbahn-Richtung der Bahnhofsstraße fahren oder hat der eine abgetrennte Spur? (Doppelte durchgehende Markierung reicht als bauliche Trennung.)
In Summe nicht schlecht, weiter so.
Bei den Stop_position würde ich Name und/oder Referenz (soweit vorhanden) angeben, damit eine Zuordnung nicht nur über die räumliche Nähe oder eine stop_area erfolgen kann. Aber das wird unterschiedlich gesehen und kann auch später ergänzt werden.
wiki hin - wiki her: ich mach beide (platform und stop_position) in die relation rein - jeweils mit entsprechender rolle. Dann hat die Anwendung “freie Auswahl”
so stehts auch im neuen Schema “Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.”
Nicht nur den ÖPNV-Betreiber selbst dürfte die stop_position interessieren. Auch wenn man beispielsweise solche (Pseudo-)Live-Karten hat, muss man schließlich wissen, an welchen Punkten die Wartezeiten stattfinden bzw. zwischen welchen Punkten interpoliert werden muss. Platform ist ja klar, beispielsweise um Leute zur nächsten Haltestelle einer gewünschten Linie zu routen.
Wer mit Plandaten arbeitet, braucht die Haltestellen, obwohl in Ulm z.B. keine Haltezeiten eingerechnet sind.
Wer mit Ist-Daten (wie z.B. die Niederländer) arbeitet, braucht die Haltestellen vor allem, um zu zeigen, dass ein Halt planmäßig ist und nicht etwa irgendwo auf der Strecke vor einem roten Signal.
Die spannende Frage “Bekomme ich meinen Zug noch” kann man dann live auf dem Smartphone verfolgen.
Unabhängig von oben geschriebenen, sind die Haltestellen natürlich sinnvoll zur Orientierung, sowohl auf der Karte als auch im Real-Life.
Nicht meine Baustelle 
