both_ways ist gem. Proposal (nur) für 2-Richtungs-Wege vorgesehen. Von Sperrflächen ist da keine Rede.
.
.
.
Wo wurde das vor Deiner Nutzung von both_ways für Sperrflächen diskutiert?
.
.
.
Kannst Du das mal ausführlicher Begründen.
.
.
.
Ich bin weiterhin der Meinung, das Sperrflächen keine both_ways im Sinne des Proposals sind und bei Bedarf für Sperrflächen ein eigenes Tagging diskutiert werden sollte.
Edit:
Auf welcher normalen Straße - außer Zufahrten zu Krankenhäusern etc. - gibt es eine Fahrspur nur für Rettungsverkehr?
Es gibt Information, an welchen Stellen Rettungsfahrzeuge mehr Platz zum Durchkommen haben.
Damit habe ich kein Problem. Hast Du einen Vorschlag, der auch gleich die genaue Position auf der Straße mit darstellt? Sperrflächen gibt es ja nicht nur in der Mitte der Straße. Wenn wir eine vernünftige Lösung erarbeitet haben, kann ich gerne mein bisheriges Tagging umstellen. Das geht allerdings nur, wenn es nicht vorher gelöscht wurde. Bis dahin behelfe ich mir halt mit der Krücke: lanes:both_ways + access:both_ways=no + emergency:both_ways=yes
Zum Beispiel vor Tunneleinfahrten gibt es die manchmal. So viel ich weiß, sollte nach dem Umbau, hier eine sein, bin allerdings leider noch nicht dazu gekommen, Fotos zu machen und das dann zu mappen.
lanes:both_ways=1
markiert ist.
Wie ich schon mehrfach geschrieben habe, halte ich die Verwendung von “both_lanes” für Sperrflächen für einen Mißbrauch dieses Merkmals.
Statt “both_ways” könnte man ja ein neues Merkmal
lanes:SPERRFLÄCHE=1
verwenden.
Wie lautet den die britisch englische Bezeichnung für Sperrfläche ?
Wenn du ein neues Tag suchst, dann gehört da kein “lanes:*” rein. Key:lanes ist nunmal als Spur für zweispurige Fahrzeuge definiert.
Außerdem brauchst du deutlich mehr Informationen, es muss möglich sein anzugeben, zwischen welchen Spuren sich die Sperrfläche befindet.
Bis wir den momentanen Workaround mit “both_ways” für mittige Sperrflächen los werden, ist einiges an Planungsarbeit nötig wenn das neue Tag auch wirklich nutzbar sein soll.
Da gibt es keine einheitliche Vokabel für, es geht nach der Funktion. Breite schraffierte Mittellinien heißen “median strip”, Sperrflächen an Einmündungen/Abfahrten heißen “painted islands”.
Deutsche Autofahrer stehen manchmal irritiert for einer “box junction”, wo die gesamte Kreuzung ein doppelt schraffierter Sperrbereich zu sein scheint. Man darf über die Box drüberfahren, aber nicht drin stehenbleiben (also erst reinfahren, wenn dahinter alles frei ist - das ist in D natürlich nicht anders, aber nicht markiert).
Wie du diesem Thread entnehmen kannst, gibt es keine einhellige Meinung, dass diese Tags gelöscht werden können. So ist das nichts anderes als Vandalismus.
Du selbst bezeichnest die Verwendung von both_ways für Sperrflächen als gewaltige Krücke. Für mich ist das ein Mißbrauch und das werte ich als Vandalismus.
Wenn Ihr einen Bedarf für das Eintragen von Sperrflächen seht, dann entwickelt doch ein eigenes Tagging dafür, mißbraucht aber nicht das Merkmal both_ways dafür!
“Krücke” heißt nicht “das ist so falsch, das muss sofort gelöscht werden”. Eher “so wirklich passt es nicht, eine besssere Lösung ist wünschenswert”.
Jemand hat sich die Mühe gemacht, diese Dinge zu erfassen, so gut es eben bis jetzt geht. Diese Arbeit sollte erhalten bleiben und nicht blindlings zerstört werden.
überlegt wie ein neues Tag aussehen könnte und ein Proposal geschrieben?
nach anderen Diskussionen zum gleichen Thema gesucht?
andere bei der Wahl eines neuen Tags um Hilfe gebeten?
eine angemessene Zeit nach dem Stellen der Frage auf Vorschläge gewartet?
Ein solches Proposal muss gut überlegt sein, geschrieben werden, diskutiert werden, abgestimmt werden. Das geht nicht in 5 Stunden zwischen deiner Frage und deiner Löschung. Das ist und bleibt voreiliges Zerstören von Informationen.
Warum fragst Du das mich ?
Habe ich both_ways mißbraucht ?
Das ganze kommt doch von skyper und Du unterstützt sein Tagging. Also warum legt ihr nicht los ?
Ich habe schon etliche Zeit (Jahre) dieses Tagging für Sperrflächen verwendet. Daran gestört hat sich niemand, bis vor ein paar Wochen. Persönlich sehe ich es mehr als Erweiterung aber nicht als Mißbrauch, aber 100% zufrieden bin ich damit auch nicht. Jetzt aber, eine Diskussion darüber anzustossen und nicht einmal das Ergebnis abzuwarten und sich die Meinungen anzuhören, sondern nach zwei Tagen mit dem Löschen Tatsachen zu schaffen, halte ich für zumindest bedenklich. Auch finde ich es falsch das Tagging als Vandalismus abzukanzeln und @mueschel und mich in die Ecke von Missbrauch und Vandalismus zu stellen. Dadurch wird die Diskussion quasi abgewürgt und es bleiben nur verhärtete Fronten übrig. Daher bitte ich Dich, @PT-53, Deine Vorgehensweise und Anschuldigungen noch einmal zu überdenken.
So ganz genau habe ich auch noch nicht kapiert, was das genaue Problem sein soll. Das ganze Spurtagging ist halt so entstanden, aber gibt es überhaupt ein einziges Proposal zu dem Thema über das abgestimmt wurde? Die Dokumentation im Wiki ist ja alles andere als in Stein gemeißelt
Ehrlich gesagt, weiß ich leider nicht wie lanes=* plus lanes:(forward/backward/both_ways)=* zur Zeit von Routing- und Darstellungssoftware verwendet wird und kann mich nur an die schwere Geburt vor ~14 Jahren errinnern. So bin ich etwa keineswegs davon überzeugt, dass es sinnvoll ist z.B. exklusive Busspuren dazuzuzählen, aber Sperrflächen welche die gleiche Breite haben nicht. Da fände ich es schon eindeutiger entweder nur Spuren für den allgemeinen Verkehr oder eben alle Flächen, welche breit genug für “normal” vierrädrige Fahrzeuge sind, zu zählen. Meine einfachste Lösung wäre daher, lanes=* oder zumindest lanes:(forward/backward/both_ways)=* aufzuweichen, da die Software ja schon heute die ganzen access-Tags mit :lanes(:*)-Erweiterungen auswerten sollte. Eventuell finde ich die Monate mal entsprechend viel Zeit, um diesen Vorschlag zu dokumentieren, damit es eine Grundlage gibt.
Wenn es wirklich ein neuer Tag sein soll, ist restricted_lanes oder block_lanes eventuell ein Ansatz. Allerdings brauche ich dann auch die Suffixe :backward, :forward und both_ways, da sonst jeder Editor beim Umdrehen der Wegrichtung das Tagging beschädigt. Zusätzlich bezweifele ich, dass diese Lösung, das eh schon komplizierte Spurtagging wirklich erleichtert und es werden wohl Jahre vergehen, bis es entsprechende Unterstützung der Editor-Software gibt. (Bei iD fehlt ja bisher das Spurtagging komplett.) Von den ganzen anderen Anwendungen ganz zu schweigen.
