Nachdem meine Änderungen für die Linie 208 mittlerweile im Verkehrslayer sichtbar sind und es auf den ersten Blick meines nicht ganz geübten Auges ganz gut aussieht, bin ich mutig geworden und habe die Gegenrichtung, zunächst nur mit den Haltestellen in der Fahrtrichtungsreihenfolge angefangen. Dazu habe ich den bisherigen Layer dupliziert, Start und Ziel vertauscht, alle members gelöscht und die Haltestellen nacheinander eingegeben und hochgeladen. Frage, was hat es mit dem key name in der Relation auf sich? Kann der beliebig gewählt werden oder ist er irgendwie vorgegeben? In der 3648223 ist der Name De_VVS_208, in der neuen, noch unvollständigen, Relation 5967281 heißt er (noch) genauso, weil sie ja durch eine Kopie erzeugt wurde. Kann man ihn anders nennen, z.B. um die Richtung anzudeuten? Nächste Frage: können in der Relation alle Routenwege in der Fahrtreihenfolge nach den Haltestellen stehen oder müssen die einen Bezug zur Haltestelle haben? Bitte um Antwort, bevor ich die Mapper beschäftige, wenn alles versaut ist!
Abend,
in der schon existierenden Route scheint am Bahnhof noch eine kleine Wegstrecke zu fehlen. ( http://www.openstreetmap.org/relation/3648223/history#map=19/48.82716/9.30330 ).
Bei den Namen der einzelnen Strecke ist nach Proposal folgende Anordnung vorgesehen:
name = “ : => ”
In deinem Fall also
name = Bus 208: Waiblingen Galgenberg => Waiblingen Bahnhof
Die Gegenrichtung müsste demnach wohl
name = Bus 208: Waiblingen Bahnhof => Waiblingen Galgenberg
heißen.
Zur zweiten Frage:
Es sollten (nach Proposal und wie in Post #6 beschrieben) zunächst alle Haltestellen von Start nach Ziel aufgelistet werden (S1,P1,S2,P2,…,Sn,Pn) und dann die Wegelemente von Start nach Ziel (W1,W2,…,Wn).
Gruß
Hubert
Guten Morgen Hubert,
vielen Dank für Deine Hilfe. Die Lücke habe ich geschlossen, den Routennamen gemäß Proposal geändert und die Gegenrichtung der 208 (Bahnhof → Galgenberg) mit dem Fahrweg komplettiert (http://www.openstreetmap.org/relation/5967281/history). Was die Linie 208 in beiden Richtungen betrifft, bin ich jetzt ganz zufrieden. Ich hoffe, Du auch 
Was mir an mehreren Stellen aufgefallen ist, ist, dass vermutlich im Verlauf der Vorgeschichte einzelne Haltestellen der 208 (und auch andere Linien) jeweils als Relation angelegt wurden, z.B. id #378918 (Schwanen, 2 members) oder #376990 (Schmidener Straße, 1 member). Kann man diese Relationen unbedenklich löschen oder haben sie noch irgendeine Bedeutung? Für die 208 habe ich sie jedenfalls nicht verwendet, sondern bei Bedarf die Haltestellen neu angelegt.
BTW: In Waiblingen scheint es außer mir nicht viele Editoren zu geben, die regelmäßig für Waiblingen an OSM arbeiten. Das sieht man schon an den Hausnummern, die außer in meinem Wohngebiet (Galgenberg) nur sehr sporadisch erfasst wurden. Schade eigentlich.
Jein: https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dstop_area Deine neugemalten haltestellen müssten also in diese Relationen integriert werden, da ist jetzt einiges doppelt. Keine Ahhnung ob diese Relationen dann als Kind-relation in die Bus-Linie reinmüssen…
@MKnight, so wie ich es bisher einschätze, sind das lediglich Relationen, die nur eine einzige Haltestelle beschreiben und keinen Bezug zu einer Linie oder einer Route haben. Daher die Frage, ob ich sie zur Entschlackung einfach entfernen soll/kann. Grüße
M.M.n. sollten Daten solange Sie nicht falsch sind oder “stören” auch nicht gelöschte werden.
“Entschlackung” ist kein gutes Motiv.
Moin,
nochmals: Nein!
Bisher hast Du nur Haltestellen erneut eingetragen (verdoppelt) - und noch nichts zerstört.
Bei dem Beispiel Schwanen hast Du die nördlich der Straße gelegene Haltestelle direkt neben die vorhandene (1406581823) neu (3999412891) eingetragen - wieso?. Du kannst doch problemlos die bereits vorhandene verwenden.
In die Relation #378918 gehört sowohl die alte nördliche (1406581823) wie Deine neue südliche (3999412890) jeweils mit der Rolle “platform” hinzugefügt.
Diese Relation beschreibt eine Haltestelle mit allen Elementen für alle Richtungen - sie wird nicht in der Routen-Relation verwendet - aber deswegen ist sie noch lange nicht einfach zu löschen.
Nichts für ungut - aber da ist noch Luft nach oben, soweit es Deine Lernkurve betrifft. 
Gruß
Georg
Hi Georg,
ich habe nicht behauptet, dass ich ausgelernt habe, ganz im Gegenteil 
Immerhin beschäftige ich mich erst seit dem 8.2.16 mit Buslinien! Während der Diskussion habe ich mich vorläufig entschlossen, neues nur mit dem neuen Schema anzulegen und darin platform und nicht stop_position zu verwenden, da die Haltestellen für die beiden Richtungen nicht immer gegenüberliegen. Und wenn bereits andere Relationen mit einer Haltestelle verknüpft sind, will ich nicht einfach den Stil der Haltestelle ändern. Das ist gerade z.B. beim ‘Schwanen’ der Fall, bei dem bei einer dieser Haltestellen die Buslinie 207 ein member ist. Du darfst Dir gerne die Relation der 207 anschauen, damit Du siehst, in welcher Qualität bisher in Waiblingen gearbeitet wurde. Die werde ich demnächst auch anpacken.
Eine spezielle Frage an alle: Ich habe heute eine neue Buslinie 218 from the scratch angelegt:
http://www.openstreetmap.org/relation/5969073/history
Sie durchfährt einen Kreisverkehr. Habe ich den richtig includiert? Zunächst wollte ich in Segmente aufteilen, aber es kam ein Warnhinweis, da er auch von anderen Buslinien befahren wird. Daraufhin habe ihn komplett eingefügt!
Grüße
Diese stop_area-Relationen sollen die einzelnen Teile einer Haltestelle zusammenfassen. Das kann bei großen Haltestellen allein schon im Interesse des Mappers gut sein. Bei unübersichtlichen Haltestellen (“Da gehen Sie da hinten über den Parkplatz und dann nach rechts. Dann sehen sie die Haltestelle der Linie 4711”) kann es auch für Karten in Apps usw. gut sein, denn dann kann ohne Probleme der Name der Haltestelle in ein schön eingerahmtes Gebiet geschrieben werden und die die Steignummern (z.B. local_ref=5) werden an die einzelnen Haltestellen geschrieben.
Stopareas muss man nicht machen – man darf es. Stopareas mit nur einem Element lösche ich: die sind ganz sicher unsinnig. Alle anderen lasse ich in Ruhe, denn sie sind ja nicht falsch … auch wenn ich sie oft unsinnig finde. Ganz schlecht sind unvollständige stop_areas: die führen den Mapper und ggf. die Reisenden in die Irre. Alle stops und platform (auch die ohne public_transport=x) gehören da rein mit den Rollen “stop” bzw. “platform”. Wenn man also ein neues Objekt anlegt, dann muss es auch in eine evtl. vorhandene stop_area rein.
Man darf auch noch mit der leeren Rolle zugehörige “amenity=x” und “public_transport=station” aufnehmen … muss man aber nicht. (Die entrance-Einträge am Bahnhof gehören also nicht rein).
Der Name der stop_area ist derselbe wie der aller seiner “stop” und “platform”-Einträge. (Der Name an der stop_area des Bahnhofs ist also falsch)
Stopareas sind nie Mitglieder von Routen. In die Routen kommen nur die Einzelobjekte. Die können natürlich auch noch in einer stop_area und in anderen Routen genannt werden.
Weide
Bei einigen Haltestellen-Nodes ist kein highway=bus_stop vorhanden. Das ist erlaubt. Aber nur die Nodes mit highway=bus_stop sind in den meisten Karten sichtbar.
Wenn an einer Haltestelle sowohl die Halteposition als auch die Platform vorhanden ist (Bahnhof), dann müssen beide in die Route. Sie müssen nicht vorhanden sein, aber wenn sie da sind, dann müssen sie rein. (Unmittelbar nacheinander. Zuerst der stop). Das hat den Sinn, dass man in der Datenbank die Routen nachschlagen kann in denen das ausgewählte Ding vorkommt. Diese Liste sollte dann komplett sein.
Weide
Moin,
Ich gebe zu bedenken:
Auch Stoparea-Relationen mit nur einem Element sollte man nicht gleich löschen.
Sie sind per se unvollständig - aber nicht unbedingt per se falsch. (*)
Warum sie also nicht vervollständigen - oder zumindest zum Vervollständigen bestehen lassen?
(*) Unvollständig ist zwar ein schlechter - aber in OSM ganz allgemein nicht gerade seltener - Zustand.
Den sollte man verbessern (vervollständigen) - aber nicht noch schlechter machen (löschen).
Gruß
Georg
Hi Weide, damit hast Du mich ins Grübeln gebracht, ob meine Idee so gut war, die Haltestellen (nur) mit der neuen Methode, also bus=yes; public_transport=stop_position bzw. =platform zu beschreiben oder ob es nicht besser gewesen wäre, auch zusätzlich highway=bus_stop mit hineinzuschreiben. Bei manchen existierenden Haltestellen steht sogar nur amenity=bus_stop dabei. Ich dachte bis vor kurzem, d.h. bis gestern, es wäre besser, entweder die eine oder die andere Methode anzuwenden und dann natürlich die neue. Wenn die aber in manchen Karten event. gar nicht dargestellt wird, ist das natürlich weniger schön. Da in vielen Anwendungen Karten verwendet werden, die auf OSM basieren könnte ich mir vorstellen, dass der entsprechende Renderer nicht alle Methoden und Flags unterstützt.
Was meint ihr dazu?
Grüße
Moin,
das ist ja auch völlig ok. (In der Hoffnung, dass das Neue besser ist - bis es von Neuerem überholt wird )
Der Grundgedanke ist stimmig - aber die Umsetzung führt nur zu einem Teilerfolg (siehe Posting Weide)
Nach einiger Zeit wirst Du selbst erkennen, dass Du damit eigentlich auch nur unvollständige Relationen erzeugst - wie der Vormapper bei der 207.
Hier unterliegst Du einem Missverständnis:
Du änderst gar nicht den Stil der Haltestelle, wenn Du das vorhandene Objekt in einer weiteren Relation benutzt - das ist grundsätzlicher Sinn der Relationen.
Und eine Relation ist eben niemals Member eines Objektes - immer umgekehrt.
Daher besteht eben kein Grund, das gleiche Objekt noch einmal neu anzulegen - damit erzeugst Du Dir nur Mehrarbeit - erst beim Anlegen, und dann beim Aufräumen.
Habe ich. Sie ist eindeutig nicht vollständig und veraltet - aber sie ist eben auch schon 6 Jahre alt in ihren Grunddaten.
Sie zu überarbeiten ist ein guter Vorsatz - nur an der Durchführung solltest Du halt noch etwas feilen.
Sonst schimpft in 6 Jahren wieder einer über Deine Arbeit.
Gruß
Georg
Moin,
Meine Vorgehensweise:
Erfassen der Busrelation nach PT2. (So ich denn mal dazu komme.)
Taggen eines Platform-Nodes mit highway=bus_stop.
Das Rendern einer Haltestelle nach highway=bus_stop ist so simple, und die Darstellung in einer allgemeinen Karte aussagekräftig genug, dass PT2 diesbezüglich noch lange brauchen wird, sich allgemein durchzusetzen - von der Umstiegsproblematik (doppelt oder gar nicht) ganz zu schweigen.
Hier kann man nur auf eine Verkehrskarte hoffen, die sich traut, nur nach dem einzig wahren - welchem auch immer - PT-Schema zu rendern, damit die Erfassung den Schub bekommt, den sie braucht, um allgemein anerkannt zu werden.
Andererseits:
Was ist denn so schlimm an dieser Doppelerfassung, solange die beiden Erfassungs-Schemata eindeutig auseinanderzuhalten sind - wenn denn der Auswerter jeweils das richtige ignoriert.
Gruß
Georg
Da hab ich mich nicht klar ausgedrückt: Zuerst kommt das Vervollständigen der Stopareas. Danach lösche ich Einelementige. (Die sind nicht per se unvollständig – PTv2 hat keinerlei Regeln, dass jeder Halt mit zwei Objekten erfasst werden muss oder auch nur soll.)
Natürlich würde ich eigentlich gern noch mehr löschen 
Es gibt massenweise Stopareas mit zwei Platforms und zwei stop_positions, die sich ohne jeden Informationsverlust durch einen einfachen Node mit highway=bus_stop auf dem Fahrweg ersetzen lassen. Da frage ich mich oft, ob der Mapper wusste dass das mit PTv2 problemlos geht.
Weide
Das “entweder oder” gilt für die Routen. Da muss man sich entscheiden, ob man die alten oder die neuen will. Derselbe Eintrag bedeutet in einer neuen Route etwas anderes als in einer alten. Deshalb gilt da “entweder oder” und man darf nichts vermischen. Das ist völlig richtig.
Bei den Haltestellen ist es anders. (Das muss auch so sein, denn sonst hätte man zum Umstieg auf PTv2 die ganze “Welt” auf einen Schlag ändern müssen) Die nur mit alten Tags versehenen Haltestellen können problemlos in neuen Routen benutzt werden und müssen nicht geändert werden.
Bei der Kartenerzeugung werden die neuen Haltestellenangaben nicht gern verarbeitet, weil es sehr schwierig und in gemeinen Fällen sogar unmöglich ist. Man muss ja keine stop_position haben, wenn eine platform da ist. Man muss aber auch keine platform haben, wenn eine stop_position da ist. Es können aber auch beide da sein. Man kann also beim Erzeugen einer Karte nicht einfach sagen ‘Es reicht, wenn ich an alle stop_positionen ein “H” mache’. Nur mit platforms geht es aber auch nicht. Und wenn man beide nimmt, dann sind zuviele davon auf der Karte. Für alle komplizierteren Regeln müsste man herausfinden, welche stop_positions zu welchen platforms gehören. Das ist schon eine schwierige Aufgabe, wenn es überhaupt keine Fehler in Routen gibt. Da ist so ein highway=bus_stop viel einfacher: “wenn eines da ist, kommt ein “H” da hin. Fertig”. Deshalb denke ich, dass das highway=bus_stop nicht aussterben wird.
Weide
Hi Georg und Weide,
vielen Dank für Eure Hilfestellungen und Anregungen.
Ich habe in den Haltestellen-Nodes ‘meiner’ Linien 208, 218 und seit neuestem auch 207 immer public_transport=stop_position bzw. =platform UND highway=bus_stop gesetzt. Ich hoffe, das stört niemanden beim Rendern. Zum Andern ist es natürlich vollkommen richtig, dass es lange dauern wird, bis highway=bus_stop verschwindet und auch lange bis alle public_transport=stop_position verstehen. Insofern könnte man es sich eigentlich einfach machen und wirklich nur highway=bus_stop verwenden. Die weniger gebräuchlichen keys wie bench, shelter, bin etc. könnte man auch weglassen, denn wer stellt die schon dar?
Stimmen meine Routen-Relationen syntaktisch, oder muss ich noch zwingend etwas ändern? Es wäre schön, wenn jemand drauf schauen könnte, z.B. bei der 207, Relation #5972012.
Hießen die Routen früher nicht route sondern line? Gerade für die 207 habe ich einige unvollständige ‘line’-Ansätze gefunden. Von den Haltestellen ganz zu schweigen. Manchmal gibt es an einer Haltestelle bald 6 nodes, weil manche die bisherigen nicht verwenden wollen, vielleicht weil sie Angst haben, anderer Arbeit zu zerstören, in dem sie die nodes modifizieren.
Ulli
Ja, aber nur kurz. Die Unterscheidung von Halteposition und Passagierposition und die Zusammenfassung der Halteangaben zu Gruppen und die Aufteilung der Gesamtlinie in mehrere einfachere Relationen kam durch ein Papier von Oxomoa. Das enthielt aber keine konkreten Vorschläge für das Tagging. Dadurch ist damals das Ganze auf viele Arten ausprobiert worden. In einer Gegend … ich glaube es war hauptsächlich Aachen … hatte man begriffen, dass neue und alte Routen nicht vermischt werden dürfen. Deshalb wurde mit type=line und line=bus statt type=route und route=bus usw. gearbeitet. Als dann der PTv2-Vorschlag kam und abgestimmt wurde sind viele dieser line=bus-Angaben übrig geblieben.
Weide
Ich hab mal die 208 genommen. Die sieht schon viel besser aus als die meisten Routen, die ich sonst so sehe
Hier die Liste:
Am Bahnhof existiert auch eine Halteposition. Die kommt mit der Rolle “stop” vor die zugehörige Platform in die Route. Das ist das Prinzip: Wenn beide da sind müssen beide rein.
Eine platform der “Ludwigsburger Straße” hat kein highway=bus_stop. Das betrifft aber nur die Kartendarstellung. Ist kein Fehler.
Schmiedener Str.: siehe Bahnhof
Schmiedener Str.: Da sind auf der Südseite zwei Platforms. Sind da real auch zwei? Wenn nicht, würde ich die beiden sehr nah zusammenschieben und im JOSM mit “m” wie “merge” zusammenfassen. Die Relationsmitgliedschaften bleiben dabei ganz.
Schmiedener Str.: Das gibt es eine stop_area. In die müssten die anderen Teile auch noch rein.
Schwanen: Auf der Nordseite der Straße sind zwei Platforms und die stop_position muss noch in die Routen.
Boskopweg: etwas südlich fehlt ein Straßenstückchen
In der Gegenrichtung Galgenberg => Bahnhof müssen die Fahrwege noch nach hinten.
Marktgasse: Da müsste auch die platform rein (hinter den stop). Beim Paar stop_position-platform darf nur einer der beiden highway=bus_stop haben.
Wenn Du willst kann ich die beiden Stopareas am Bahnhof reparieren und eine Masterrelation für die 208 hinzufügen. Nichts davon ändert etwas an den Routen.
frohes Mappen
Weide
Immerhin
Der Bahnhof ist sowieso ein Sonderfall. Eigentlich müsste das Layout komplett überarbeitet werden, siehe Haltenstellenkarte: http://www2.vvs.de/Download/Envmaps/vvs/uWaibl.pdf. Die Haltepositionen sind Bussteige rund um den Bahnhof, die Busse fahren in einer Schleife um den Bahnhof und die Bussteige herum, wobei die Bussteige eigentlich nur ein Gehweg am Rand des Bahnhofs darstellen. Eigentlich dachte ich, dass public_transport=platform statt stop_position benutzt werden muss, wenn der Einstieg nicht auf der Straße, sondern vom Gehweg aus ist und außerdem die Haltestellen in den beiden Fahrtrichtungen nicht direkt gegenüber liegen und event. andere Eigenschaften haben. Außerdem muss stop_position ein node der Straße sein. War das ein Irrtum?
Korrigiert.
Schmidener Straße könnte ich aus heutiger Sicht nur als stop_position spezifieren, da sie direkt gegenüber liegen und in beiden Richtungen der dort fahrenden Busse bedient werden.
Es ist nur 1 Haltestelle am Straßenrand.
Wie gesagt, die Haltestlele könnte ich überarbeiten, aber was ist mit den nodes, die nicht von mir sind und Bestandteil einer anderen Relation sind?
Wie Schmidener Straße
Eingefügt!
Ein Stück gab es schon in einer anderen Relation, aus der habe ich ‘meine’ Relation abgeleitet. Aber jetzt habe ich die stops nach vorne gesetzt.
Wie bei Schmidener Straße. Ein stop würde hier reichen.
Ich will, schon damit ich ein Muster habe. Aber wie gesagt, mit dem Bahnhof bin ich nicht zufrieden, aber das ist etwas Größeres, weil viele Relationen dabei sind. Eine Masterrelation würde mir gefallen, denn damit kann wohl man beide Richtungen zusammenklammern, oder?
Danke für Deine Mühen
Ulli