Name wäre dann an der Fläche und die Routenmitgliedschaften der einzelnen Haltepunkte müßten dann noch zugeordnet werden, hatte ich ja geschrieben.
Verstehe ich nicht.
Nein, den Mast setze ich konsequent als Punkt. Eigentlich wäre pole_position der passende Begriff, aber darunter verstehen die meisten was völlig anderes 
Deshalb eben public_transport=platform als Punkt an der Stelle, wo das Mastschild steht.
Solange das nicht gerendert wird, noch highway=bus_stop dabei.
Und diesen Punkt mit dem Namen “Wetzlar Busbahnhof” (eventuell noch Bussteignummer dazu) versehen als Mitglied in der Routenrelation. Sonst hast du nämlich namenlose Knoten in der Relation und weisst ohne Hinzoomen nicht, welche Haltestelle das nun sein soll.
Den Bahnsteig lasse ich als große Fläche, auch bei Bahnen.
Gruß,
ajoessen
Mit namenlosen Knoten tust du dir in der Relation keinen Gefallen.
Gruß,
ajoessen
Hallo liebe Mitstreiter. Da ich den ZOB in Wetzlar in seiner jetzigen Form zu “verantworten” habe, möchte ich zuerst einmal deutlich machen das ich Eure Überlegungen in keinster Weise als “runtermachen” empfinde. Wo kämen wir denn da hin, wenn sich jeder Mapper bei einer abweichenden Meinung gleich auf den Schlips getreten fühlen würde. Bei mir ist das zumindest nicht so. 
Im Gegenteil, ich bin froh das Radeln diesen ZOB mal aufgegriffen hat, denn ich war mir beim Eintragen von verschiedenen Dingen nicht ganz sicher wie es richtig sein sollte und hätte früher oder später diese Fragen selbst hier aufgeworfen.
Laut WIKI sind bei einigen Tags verschiedene Dinge möglich, als node, als Fläche, oder auch beides möglich.
Das überspannende Dach gibt es tatsächlich, die tatsächliche Ausführung kann jedoch etwas abweichen (hatte mein Lasermessgerät grad nicht zur Hand 
).
Ob das einbinden der “Stoppunkte” in die Busrouten, auf die Fahrspur oder als separate Haltebucht war mir auch nicht so klar… Irgendwie ist mir die Geschichte mit den Relations und den dazugehörigen Haltestellen noch nicht so ganz klar.
Die von ajoessen genannte Ähnlichkeit ist nicht zufällig. Wie ihr unter “source” feststellen könnt, hat hier die ansässige Tageszeitung geholfen. Die restlichen Hinweise/Erkenntnisse habe ich von eigenen Begehungen und Fotos. Es gibt dort eine wunderbare Brücke siehe hier, von der man fast schon aus der Vogelperspektive den ZOB vor(unter) sich hat.
Also lange Rede kurzer Sinn, ich würde mich freuen wenn sich die ÖPNV-Spezialisten hier einbringen würden und auch direkt Hand anlegen und den ZOB/Bahnhof (offizielle Schreibweise auch an/in den Bussen!) so “herstellen” wie es richtig ist. Im Juni findet in Wetzlar der Hessentag statt. Es wäre toll wenn der Fall bis dahin erledigt wäre.
Mir ging es in erster Linie darum die neue Situation am ZOB/Bahnhof zeitnah in OSM zu bringen. Die Eröffnung war gestern (04.03.12)
Das “oneway” war natürlich falsch, habe es entfernt.
Georg
Namenlos? Liniennummer für die Haltepunkte sollte wohl reichen.
Siehe Posting #20. Wenn die Masten so wichtig sind, sollten diese anders gemappt werden, aber bitte nicht als Haltepunkte. Ob nun public_transport=stop_position oder highway=bus_stop oder beides. Gehören auf jeden Fall an die Straße (Posting #20).
Dann schau dir mal die Linienrelation an:
der Bus hält an Punkt 23819283, 38291938, 3892000,38293827.
Da weiß man auf Anhieb, wo das ist, und ob die Reihenfolge stimmt? Oder eben nicht.
bei mir steht da der Name der Haltestelle.
Gruß,
ajoessen
Woher nimmst du diese Information?
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Platform
“A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole.”
Außerdem ist area=* explizit als Key value paar eingetragen.
Das ÖPNV-Schema funktioniert so:
- Die Plattformem bzw. wenn man sie nicht erfassen kann bzw. hat, dann ersatzweise das Haltestellenschild, werden mit public_transport=platform (und, je nach Fall, z.B. bus=yes (an der Plattform macht das aus meiner Sicht noch mehr Sinn, wenn man das taggen möchte, als an den Haltepunkten)) getaggt.
- Die Halteposition des Verkehrsmittel, die üblicherweise beim Bus auf der Fläche der Fahrbahn liegt, wird mit public_transport=stop_position getaggt.
- Die Gesamthaltestelle sind alle Objekte aus 1. und 2., die den gleichen Namen haben. Die kommen in eine Relation mit public_transport=stop_area. Damit ist dann die “Haltestelle” als solche (man weis dann den Namen und was alles mit dazu gehört) definiert.
- Die Route besteht aus einer Abfolge von Wegen und Haltepunkten, die der Bus der Reihe nach abfährt und sollte dann, nach neuem Schema, als eine Relation pro Richtung, ohne spezielle Rollen für die Haltepunkte oder Wege definiert werden sollte. Soweit ich aber gesehen habe, handhabt man es aber bisher nach altem Routen-Schema und nimmt die Haltepunkte anstelle der alten highway=bus_stop’s in die Relation auf.
Auch das steht hier explizit anders:
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route
“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.”
Was meinst du genau mit Haltepunkte? Die Relation der Gesamthaltestelle?
Mich wundert nicht, dass es viele anders (ich will ja gar nicht sagen falsch) Handhaben, da man sich das Wissen aktuell aus 2 Schemas und 3 Proposals (davon die hälfte Englisch) zusammenziehen muss. Irgendwie fehlt mir da eine grundlegende Übersicht.
Hab mich jetzt mal durch [1] und [2] gearbeitet, und bin auch auf ein anderes Ergebnis gekommen. Kann nirgends finden, dass sie keine Rolle haben sollten. Speziell bei [1] wird der stop_position und der Platform eine Role gegeben, je nachdem ob man ein und/oder aussteigen darf.
Mit route, line, route_maste, line_variant sind sich die beiden aber auch nicht einige. Irgendwie sollte sich da mal ein Schema durchsetzen.
[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route
[2] http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Network_information_.28lines_and_routes.29
Routen habe ich bisher noch nicht getaggt, nur viele Haltestellen, und natürlich sollte man es im Zweifelsfall so machen, wie das Proposal, einfach wegen der Einheitlichkeit und Auswertbarkeit.
Datentechnisch nötig, und davon bin ich oben ausgegangen, ist es aber nicht. Da muß man nicht in der Routen-Relation irgendwelche Rollen angeben, das ist nur redundant, da die Info, ob es eine Plattform oder ein Haltepunkt ist, ja schon an den Objekten selbst steht. Soll heißen: man geht alle Objekte der Routen-Relation durch und was es jetztlich ist, steht dann direkt am Mitgliedsobjekt. Den Namen der Haltestelle, wenn man nur den Haltepunkt der Route hat, bekommt man dann darüber, daß der Haltepunkt, ja Mitglied einer Gesamthaltestelle (public_transport=stop_area) ist, die dann natürlich einen Namen hat.
Die Taggingpraxis in Bezug auf die Routen war ja auch lange schwamming bis unklar, einfach schon, weil nicht klar war, ob man wie im Orginalentwurf route=line benutzen sollte. Nachdem das ganze dann schon 'ne Weile in Benutzung war, hat man es dann im Proposal zu type=route_master geändert, soweit ich weiß. Im Orginalentwurf (http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema#Linienvariante) kommen die überflüssigen Rollen in der Linienrelation auch nicht vor. Die stop_area_group habe ich ja noch vor der Abstimmung gekickt, das mit den Rollen für die Routen habe ich leider erst danach gesehen.
Da meine ich die Knoten mit public_transport=stop_position.
Noch 'ne Anmerkung dazu, weil es mir gerade einfällt, was vielleicht der Grund ist, warum auch die Plattform mit in der Routenrelation gelandet ist, die da ja eigentlich nichts drin zu suchen hat, weil sonst müßte der Bus ja auf seiner Route auch die Plattform samt Wartehäuschen, Schild, etc. passieren. Da gab es doch das Problem, das man für den Fall, das man jemanden genau zum passenden Einstiegspunkt an Haltestelle x routen möchte, nicht weiß, welche Platform denn nun zu dem/den Haltepunkt(en) gehört. Da braucht man noch eine weitere Relation, die eben genau die Zuordnung der Haltepunkte zur passeden Platform abbildet. Nur dann jammern wieder alle, weil das ja noch eine Relation mehr ist.
Genau hier liegt das Problem! Es ist selbst bei einfachen Haltestellen mitunter kompliziert. Es kann Haltestellenmasten mit zwei Stoppositionen geben, genauso wie es Stopositionen mit zwei Masten geben kann. Spätestens dann ist nicht mehr klar was jetzt für diesen Fahrtverlauf entscheidend ist.
Ich habe mich bei meinem Tagging bisher immer nur die Masten in die Routenrelation aufgenommen, weil die anderen Dinge für mich bisher keine sinnvolle Information waren. Es gab hier mal die Verfechter, welche sagten, dass man dies brauche um den Weg des Fahrzeugs nachzuvollziehen. Da aber in den meisten Fällen die Stoppositionen weder eingetragen sind noch in der Realität physisch vorhanden sind, habe ich auf die Erfassung verzichtet. Ich habe allefalls Haltestellen auf dem Weg zu solchen umgetagt.
Natürlich hast du auch Recht, wenn du sagst das man sich den Namen aus den Überrelationen holen kann. Solange aber Josm dies nicht macht und andere Auswerter das auch nicht schaffen, wird diese Information immer redundant erfasst werden. Einfach um die Dinge besser zu sehen.
Die “platform” muss in die Relation. Gehen wir mal von der Situation, welche die Diskussion ausgelöst hat, aus:
Wenn jetzt nur der “highway” und die “stop_position” in der Realtion wäre, wodurch sollte eine Navigationslösung wissen, zu welcher “platform” sie dich leiten soll? Die Nähestgelegene fällt aus, da beiderseits der Straße eine Halteposition ist.
Wäre der betreffende Abschnitt der “platform” in der Relation drinnen, müsste einfach nur die nähestgelegene Platform genommen werden und das Navi wüsste wohin.
… und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.
Gruß,
ajoessen
Das Problem ist eigentlich nicht so kompliziert, wenn man es richtig betrachtet.
Wofür sind denn die H-Tafeln/H-Schilder da? Ja, die zeigen doch nur die ungefähre Position des Haltepunktes (beim Bus auf der Plattform) an. Damit kauen die also nur die Info “hier ist der Haltepunkt” noch mal an der Plattform wieder. Deshalb sollte man die meiner Meinung nach auch nur als Ersatz für die noch nicht erfasste Plattform nehmen, weil es eben nur der formale Hinweis auf den Haltepunkt an sich ist.
Damit ist dann auch für die Plattform (public_transport=platform) nicht die Zahl der Haltepunktschilder, sondern die der Bahn-/Bussteige entscheidend. Und wie schon geschrieben, braucht man noch eine zusätzliche Relation (fürs Routing zu den Haltepunkten/Plattformen), die die Zuordnung der Haltepunkte zu der Plattform macht, über die man die dort haltenden Verkehrsmittel normalerweise erreicht.
Dann gibt es, wie du schon geschrieben hast, zuerst den Fall das man einen Bahn-/Bussteig mit mehreren Haltepunkten hat. Da kommen die Haltepunkte und die zugehörige Plattform in die Bahnsteigrelation und der Router weis dann, auf welchem Bahnsteig man ankommt, wenn der Zug von Linie x an Haltepunkt y ankommt.
Das Problem der “zwei Masten” löst man auch über die reale Plattform, da ist ja nur eine, zumindest in Berlin, wo genau dieser Fall gerne bei Endhaltestellen vorkommt. Wenn man schon die beiden Masten hat, kann man auch provisorisch einen Weg zwischen ihnen für die Plattform mappen. Damit hat man dann wieder nur eine Plattform.
Dann gibt’s noch den Fall, das die gleichen Hlatepunkte zu mehreren Plattformen gehören können (z.B. Gleis 3 hier: http://osm.org/go/0MbGUPxS7–, da hält die S-Bahn mittig und man kann nach beiden Seiten gleichzeitig aussteigen), da sind dann eben zwei Plattformen mit in der Relation die die Haltepunkt-Plattform-Zuordnung macht.
Ja, die Stoppositionen sind nur ein Modell, wobei auch nicht ganz klar ist, ob damit die Mitte oder der Beginn des Fahrzeuges gemeint ist, ich habe Leute gesehen, die setzten die Spotposition in die Mitte der Bushaltetasche, auch wenn man es eigentlich analog zur Eisenbahn machen, und den Fahrzeugbeginn nehmen, müßte. Momentan geht es auch nicht anders, als eben die Plattform mit aufzunehmen.
Da hast du auch recht, das ist meines Erachtens auch der Hauptgrund, warum man die redundante Erfassung braucht. Gerade weil man sonst in JOSM leicht was übersieht und mit den redundanten Infos das Handling leichter ist, auch wenn das eigentlich das Wegzeug und nicht dessen Benutzer lösen sollte. Die anderen Auswerten müssen ja nichts ändern, da im Moment alles x-mal erfasst wird. Warum sollten die sich unötige Arbeit bei der Auswertung machen?
Und die Anhäufung “Bocholt Bahnhof” findest Du jetzt gut?
http://www.openstreetmap.org/?lat=49.447234&lon=11.082399&zoom=18&layers=M
- zum Großteil von mir verbrochen -
ist im JOSM erst richtig schlimm …
Zum Glück haben wir am Bahnhof selbst mit seine 26 Gleisen und 100+ Linien nicht mehr gemacht.
Ein einziges Gewusel!
Warum nicht? Ein guter Renderer schreibts nur dann hin, wenn auch Platz dafür ist:
Ist mir jedenfalls lieber, als erst mühsam alle Relationen durchsuchen zu müssen, ob da irgendwo die Information steht, die ich haben will.
Gruß,
ajoessen