Proposal für Abbiegeverbote mit Zusatzbedingungen

Ich möchte hier auch noch auf mein neues Proposal aufmerksam machen. Falls es keine größeren Probleme gibt, geht in ein paar Tagen die Abstimmung los.

Conditions for restriction relations

Es geht um Abbiegeverbots-Relationen (turn restrictions). Die können manchmal nur für ganz bestimmte Fahrzeuge oder nur zu bestimmten Uhrzeiten gelten. Mein Vorschlag ist, das mit zusätzlichen Tags an der Relation auszudrücken.

if:mode =

bzw.

if:time =

Diese beiden Tags kann man bei Schilderwäldern, wo beides gleichzeitig auftritt, sogar problemlos kombinieren. Das Grundkonzept sollte darüber hinaus flexibel genug sein, um weitere Tags dieser Art erfinden zu können, falls jemand neue Varianten entdeckt. Und wenn wir an einer anderen Relation auch mal so was ähnliches brauchen sollten, muss die Idee nicht einmal auf Abbiege-Relationen beschränkt bleiben.

Ein Wort noch zu bereits existierenden Tags auf Relation:restriction: Für Fahrzeugarten fehlt ein solches Tag komplett, das existierende “except”-Tag (das in den Situationen, für die es gedacht ist, natürlich weiterhin verwendet werden soll) deckt lediglich den Fall ab, dass die Abbiegebeschränkung für einzelne Fahrzeugarten nicht gilt. Für Zeiten gibt es day_on/off und hour_on/off, aber die funktionieren nur in ganz einfachen Fällen, die opening_hours-Syntax ist bekannt und viel flexibler.

Die Abstimmung hat jetzt begonnen.

Ich hoffe auf eure Stimmen.

Wie ich sehe bist Du mit meinem “Nein” bei der Abstimmung nicht einverstanden?
Nun werde ich ganz sicherlich nicht auf die Diskussionsseite gehen um darüber mit einem Deutschen in Englisch zu diskutieren.
Also erkläre mir doch bitte an dieser Stelle warum Zeit- und Fahrzeugdefinitionen, wie im access-Key angewandt nicht auch Anwendung auf Abbiegebeschränkungen finden können.

mfG Michael

Deine aktuelle Begründung finde ich nicht überzeugend. Aber ich bin natürlich offen für eine Diskussion.

Gerne. Vorweg: Eine solche Verwendung ist bisher nicht wirklich definiert - deshalb habe ich deiner Aussage auch so direkt widersprochen, weil sie eben das suggeriert. Auch dein Vorschlag wäre eine Neuerung. Die Tags, die an den Relationen verwendet würden, sähen zwar genauso aus wie bereits verwendete Tags, aber hätten eine etwas andere Funktion, und müssten auch anders ausgewertet werden. Dennoch ist die Lösung denkbar - aus verschiedenen Gründen fände ich sie aber nicht ideal.

Am klarsten ist das in meinen Augen bei den Zeitdefinitionen. Die einzigen Zeiteinschränkungen, die es auf der access-Wikiseite traditionell gibt, sind date_on/off, day_on/off und hour_on/off. Damit kann man aber nur ganz wenig ausdrücken. Mehrere Intervalle funktionieren nicht, Abhängigkeiten zwischen z.B. Monat und Uhrzeit funktionieren auch nicht. Aber da wir uns bei opening_hours ja schon Gedanken zu dem Thema gemacht haben, finde ich es naheliegend, die Syntax für die Werte einfach von dort zu übernehmen.

Jetzt zu den Fahrzeugdefinitionen: Die erfinde ich ja keineswegs komplett neu, sondern verweise im Proposal ausdrücklich auf die access-Tags. Die Verkehrsmittel-Namen wie “bicycle”, “bus”, “hgv” usw. werden also beibehalten. Nur halte ich es nicht für ideal, das access-Tagging 1:1 in die Abbiegerelationen zu übernehmen. Erstens wäre dann die Bedeutung nicht klar: Soll “bus=yes” bedeuten, dass dieses Abbiegeverbot für Busse gilt, oder dass Busse hier abbiegen dürfen? Zweitens ergeben auch einige der access-Werte bei einer Abbiegebeschränkung nicht viel Sinn.

Zu guter Letzt denke ich auch ein wenig an die Zukunft. Ich könnte mir durchaus vorstellen, dass in zukünftigen API-Versionen beispielsweise Tag-Gruppen eingeführt werden. Dann könnte man die if:*-Schlüssel auch gut zusammen mit normalen Wege-Attributen wie maxspeed, oneway oder eben access verwenden. Dazu will man aber erkennen können, ob der access-Tag in der Gruppe selber die Einschränkung ist oder die eigentliche Einschränkung ergänzt! Einen ähnlichen Effekt hätte es, wenn sich irgendwann der (mit den aktuellen Werkzeugen problematische…) Vorschlag durchsetzen würde, Einschränkungen über den kompletten Gültigkeitsbereich hinweg in Relationen zusammenzufassen.

Zusammenfassung: Durch die im Proposal gewählte Lösung lassen sich einige fehlende Fälle nachrüsten, die Bedeutung ist weitaus unmissverständlicher, und die Lösung ist zukunftssicher.

O.k., wenn ich das alles aber jetzt richtig interpretiere so wäre es primär sinnvoll eine Koordination mit den bereits vorhandenen access-keys zu schaffen.
Eventuell ist der Zeitpunkt für das Proposal etwas verfrüht gewählt, da noch nicht alle Unstimmigkeiten im Vorfeld ausgeräumt wurden.
Müsste ich also stimmen mit “Ja, mit Vorbehalt”, leider gibt’s aber nur die Option “Ja” oder “Nein”.

mfG Michael

Naja, du könntest noch mit ‘I dislike this proposal’ abstimmen, oder mit ja und deine Vorbehalte nebendranschreiben

Ja, Du magst Recht haben, aber im Zweifelsfall ziehe ich dann “Nein” vor um nicht etwas mit abgesegnet zu haben was dann irgendwann ins Chaos führt.
Der “Dschungel” der Keys ist schon dicht genug und was mir so ständig an falscher Verwendung dieser so begegnet ist manchmal schon haarsträubend genug.

Meinst du bereits vorhandene access-Keys an restriction-Relationen oder normales access-Tagging? Ich bin mir nicht ganz sicher, worauf du hinaus willst. Sorry, wenn ich gerade auf der Leitung stehe.

Es kam fast zwei Wochen lang kein Feedback mehr, da habe ich noch mal hier im Forum diesen Thread aufgemacht. Und als sich dann immer noch keiner gerührt hat, habe ich halt mit der Abstimmung angefangen.

Ich beziehe mich auf die allgemeinen Regeln für access-Keys definiert auf http://wiki.openstreetmap.org/wiki/Key:access
Diese Regeln müssten doch klar auf einer Seite definiert sein und nicht “solche bzw. solche keys”.
…oder liege ich da jetzt falsch?

Ich weiß nun leider nicht an welcher Stelle ein Feedback hätte kommen sollen, aber der erste Thread zu diesem Thema, aus welchem ich auch davon erfuhr, war der von Dir am 20.07. verfasste. O.k., das hatte ich zwar übersehen (schaue auch nicht jeden Tag in’s Forum), aber der zweite Eintrag von gestern fiel mir dann auf.
Du darfst nicht vergessen, dass nicht alle User überall (Forum, Mailingliste, etc.) Mitglied sind, wie auch ich.
Meiner Meinung nach sollte man, zumindest für Deutschland, sowieso alles außer dem Forum “einstampfen”, so wäre eine viel bessere Kommunikation und Koordination gewährleistet.

mfG Michael

Tja Michael,
das finden viele Nutzer der Mailing-Listen auch, dass man das Forum einfach einstampfen sollte.

Beide Forderungen empfinde ich als gleich ‘überheblich’ und unangemessen.
Es gibt nun einmal ML-Nutzer und Foren-Nutzer und nur eine geringe Überschneidung.

Mit anderen Worten: Die Abstimmung mit den Füßen hat ein klares Unentschieden ergeben.

JM2C
Edbert (EvanE)

Derzeit werden die Tags am Way selbst auf Key:access beschrieben, und die Tags für Abbiegebeschränkungen auf Relation:restriction. Ich habe erst einmal nicht vor, daran etwas zu ändern.

Es ist gut denkbar, dass die Ideen aus meinem Proposal in Zukunft auch fürs eigentliche access-Tagging relevant werden, aber dazu gäbe es dann ein Extra-Proposal.

Ich werde versuchen, beim nächsten Mal das Forum etwas eher einzubeziehen. Offizieller Kanal für die Ankündigung neuer Proposals ist aber die tagging-Mailingliste.

Da nun auch hier darüber diskutiert wird:

Ich finde ein Schema, dass auf ein Key mit mehreren values hinausläuft grundsätzlich verkehrt.
In der restriction-Relation wäre =<gültig>|<nicht gültig> immer eindeutig. Bei if:mode= erzeugt man in der Regel eine ;-separierte value-Liste, deren Auswertung schwierig bis unmöglich ist.

Das if:time=… finde ich gut und sollte sich immer auf alle Verkehrsmittel beziehen, für die die Einschränkung gilt.

Sollte es dann zu dem Fall kommen, dass bspw. Busse von 9-12 und LKW von 12-13 abbiegen dürfen, so würde ich 2 Relationen dafür nutzen.

Das Problem hier ist, dass es schon wieder die Definition der Auswertung verkompliziert. Ich will die Sache einfach halten und ausschießlich “und”-Verknüpfungen zwischen den Bedingungen zulassen.

“if:mode=bus + if:time=09:00-12:00” bedeutet, dass die Einschränkung nur gilt, wenn

Fahrzeug ist Bus UND Zeit ist 9 bis 12 Uhr

Egal, wie viele weitere Bedingungen man sich ausdenkt (es regnet, der Nutzer ist Lieferverkehr, es ist dunkel, …), alle werden mit “und” verknüpft.

Würde man so was wie “bus=yes + hgv=yes + if:time=09:00-12:00” zulassen, dann würde man von diesem simplen Prinzip abweichen. Das würde schließlich heißen, dass die Relation gilt, wenn

( Fahrzeug ist Bus ODER Fahrzeug ist LKW ) UND Zeit ist 9 bis 12 Uhr

Mit anderen Worten: Man würde auch noch ODER-Verknüpfungen und (implizite) Klammerungen einführen.

Richtig. So kann man übrigens auch generell die Verwendung von Semikolon-separierten Verkehrsmittellisten vermeiden, wenn man sie für problematisch hält: Zwei Relationen daraus machen. Eine für das Abbiegeverbot für Busse, eine für das Abbiegeverbot für LKW.

Da halte ich lieber die Auswerteregeln einfach, als in diesen selteneren Fällen eine Relation zu sparen, oder?

Edit: Ok, Nachtrag. Bei genauerer Überlegung könntest du insofern recht haben, als bei Ausnahmen dann doch häufiger mehrere Verkehrsmittelarten betreffen. Muss man wohl doch noch mal drüber nachdenken. :-/

Edit 2: Vielleicht sollten wir die Sache mal von Grund auf angehen. Warum siehst du eigentlich ein Problem in mehreren Values? Das Problem kommt normalerweise ja nur zustande, weil Anwendungen nicht darauf eingestellt sind. Aber bei Tags, wo das vorgesehen ist, kann man die Auswertung ja durchaus von Anfang an entsprechend schreiben. Du hast ja z.B. mit opening_hours bzw. if:time kein Problem, obwohl dort Dinge wie “10:00-12:00**;** 18:00-20:00” vorkommen können. Man geht eben davon aus, dass ein Tag, bei dem Wertelisten zum Konzept gehören, nicht die üblichen Probleme verursacht. Wieso kann if:mode kein solches Tag sein?

Das Problem mit den vielen values sehe ich darin, dass alle großen Auswerter dies nicht unterstützen, ebenso keiner der großen Editoren und auch die API nicht. Wenn man nun will, dass sich ein Tag durchsetzt, muss es auch ausgewertet werden, ansonsten wird es kaum verwendet.

Wie du schon selber festgestellt hast, dürfte der Normalzustand sein, dass mehrere Verkehrsarten gleichzeitig erlaubt/verboten sind. Bspw. Bus, Taxi, Fahrrad oder Anlieger + Rad …

Dann bräuchte man noch etwas um die restriction für alle aufzuheben um sie dann gezielt wieder freigeben kann. In D gibt es jedenfalls einmal die Variante, die du im proposal hast mit dem LKW unter dem Schild. Zum anderen gibt es die Variante mit Fahrrad frei etc.
Also einmal “gilt für alle außer” und “gilt nur für”.

Der Rest des Proposals wird bisher auch von niemandem unterstützt.

Ist es schwerer, eine Werteliste in einem Tag, das explizit dafür vorgesehen wäre, zu unterstützen, als die opening_hours-Syntax zu verstehen, die nicht nur Listen gleichberechtigter Werte, sondern sogar noch kompliziertere Konstrukte enthält?

Ich habe den Eindruck, du denkst etwas wie “das sind ja eigentlich access-Tags” => “es sind access-Tags mit mehreren Werten, und die sind ein Problem”. M.E. sind es keine access-Tags. Es ist eine neue Art von Tag, die eine Liste mit den von der Relation betroffenen Verkehrsmitteln als Wert hat.

Natürlich bist du nicht der erste, der hier eine Verknüpfung zu access-Tags sieht, also kann es durchaus sein, dass es meine Gedanken sind, die eher abwegig oder zumindest schlecht erklärt sind. Aber womöglich bringt uns die Diskussion noch voran.

Stimmt schon. Der Normalfall vielleicht nicht, aber doch ziemlich häufig. [Nebenbemerkung: Anlieger + Rad ist kein Problem, weil Anlieger keine Fahrzeugart sind.]

Da hast du völlig recht, dass beide Varianten nötig sind.

Als Gegenstück für if:mode=* gibt es auf Relation:restriction bereits “except”, das eine (semikolon-getrennte ) Liste von Fahrzeugtypen nimmt, die von dem Verbot ausgenommen sind. Würde ich das Tag neu erfinden, würde ich es eher “except:mode” oder “if_not:mode” nennen, aber … gibt’s halt schon.

Der Sachverhalt ist doch sehr ähnlich dem access-Taggs. Ein Objekt soll in seiner Gültigkeit beschränkt werden. Das access-Schema ist etabliert und wird von den Mappern und den Auswertern verstanden.

Und wenn du mich direkt fragst, würde ich sagen, dass es für alle am einfachsten wäre, das access-Schema nahezu 1:1 zu übernehmen. Denn warum das Rad neu erfinden?

Wenn man deinen Vorschlag weiter denkt, bräuchte man noch ein if:height if:weight und noch if:Anlieger. Dann hätte man ein paralleles access-Schema, was nur für restrictions gültig wäre, aber im Prinzip das gleiche aussagen möchte. Wo siehst du darin den Vorteil?

Wird es doch gar nicht. Zumindest nicht in dieser Ausbaustufe.

Und die Teilmenge, die von Mappern und Anwendungen derzeit üblicherweise verwendet wird, kann manche Dinge nicht abbilden.

Ja.

Wie gesagt: Das “einfache” access-Tagging hat seine Grenzen und kann nicht alles beschreiben. Also kann es nicht die Lösung sein. Man muss daher entweder

• das access-Tagging plus die noch nicht üblicherweise unterstützten Erweiterungen (“Extended conditions”) für restrictions übernehmen oder

• speziell für Relationen entworfene Tags verwenden

Die “Extended conditions” sind, wie ich erfahren musste, bei vielen unbeliebt. Die Verwendung von Dingen wie Zeitangaben in Schlüsseln wird rundweg abgelehnt, es gab sogar schon Forderungen von Entwicklern, so etwas in Editoren oder der API zu verbieten. Ähnliches gilt überhaupt für das Anhängen von Dingen an Schlüssel, weil man dann nicht mehr so einfach die für die eigene Anwendung interessanten Tags erkennen/filtern kann.

Und ich muss zugeben: So ganz unrecht haben die Kritiker da auch nicht. Aber die Idee, alles in ein einziges Tag zu stecken, ist halt eine Notlösung, weil man die Zusammengehörigkeit mehrerer Tags nicht ohne weiteres erkennen könnte. Dass man in Relationen mehrere Tags verwenden und problemlos die Zusammengehörigkeit feststellen kann, macht es möglich, für Relationen stattdessen ein deutlich saubereres Konzept zu verfolgen, als bei denjenigen Tags, die direkt am betroffenen Objekt stehen.

Die Zusammengehörigkeit von einzelnen Tags kann man auch in Relationen nicht erkennen, das wird erst eindeutig, wenn man anfängt mit geschachtelten Unterrelationen zu arbeiten. Relationen bilden nur die Zugehörigkeit von Objekten zu bestimmten Einzeltags ab. Aus meiner Sicht ist das Problem ein Fall für die API.

Die Zusammengehörigkeit der Tags, die eine bestimmte Einschränkung beschreiben, kann man deshalb feststellen, weil man eine Relation pro Einschränkung macht. So eben:

Relationen schachteln muss man dafür nicht, wieso auch? Man hat halt 2 Relationen mit denselben Membern.

Welchen Fall könnte man denn mit den normalen access-Tags + maxheight, maxwidth usw. nicht abdecken? Die Zeitliche Komponente sehe ich ein, aber gegen das if:time hab ich ja auch nichts gesagt.

Ich sehe halt die Gefahr der Verwirrung der Nutzer, wenn man 2, von der Bedeutung her ähnlichen Sachen unterschiedlich einträgt, nur weil es einmal eine Relation ist und beim anderen mal eine normale Straße.