Proposal für Abbiegeverbote mit Zusatzbedingungen

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

r-michael wrote:

Wie ich sehe bist Du mit meinem "Nein" bei der Abstimmung nicht einverstanden?

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

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.

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 😉

errt wrote:

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.

r-michael wrote:

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.

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.

Eventuell ist der Zeitpunkt für das Proposal etwas verfrüht gewählt, da noch nicht alle Unstimmigkeiten im Vorfeld ausgeräumt wurden.

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.

Tordanik wrote:

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.

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?

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 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

r-michael wrote:

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.

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)

r-michael wrote:

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?

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.

Du darfst nicht vergessen, dass nicht alle User überall (Forum, Mailingliste, etc.) Mitglied sind, wie auch ich.

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 <Verkehrsmittel>=<gültig>|<nicht gültig> immer eindeutig. Bei if:mode=<Verkehrsmittel> 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.

aighes wrote:

Ich finde ein Schema, dass auf ein Key mit mehreren values hinausläuft grundsätzlich verkehrt.
In der restriction-Relation wäre <Verkehrsmittel>=<gültig>|<nicht gültig> immer eindeutig.

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.

Bei if:mode=<Verkehrsmittel> 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.

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".

aighes wrote:

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.

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.

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 ....

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

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".

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?

aighes wrote:

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.

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.

Wenn man deinen Vorschlag weiter denkt, bräuchte man noch ein if:height if:weight und noch if:Anlieger.

Ja.

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?

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.

Tordanik wrote:

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.

Fabi2 wrote:

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.

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:

aighes wrote:

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.

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.

aighes wrote:

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.

Hmm, ich sehe da schon einen Unterschied.
Die meisten access-Regeln sagen eher "nicht für ...". Die Aussage "für ..." wird meist durch Auflistung der nicht zugelassenen Werte erreicht. Was aber bei den access-Regeln bisher fehlt, ist die Aussage "gilt nur für ...".

Es gab mal einen ähnlichen Fall in talk-de bei Parkplätzen, die nur für Reisebusse zugelassen waren. Das konnte keiner angemessen mit access-Regeln ausdrücken.

Von daher halte ich das "if:mode=..." für die Aussage "gilt genau für ..." für einen möglichen Ansatz, das einfacher auszudrücken als über viele Negationen. Weiter ist die Bedeutung von access=... für eine Abbiege-Regel überhaupt nicht definiert. Da besteht also auf jeden Fall Bedarf den Fall "gilt für ..." zu regeln.

Edbert (EvanE)

wieso? ein access=no xy=yes ist doch nur für oder etwa nicht?

Wie gesagt, ich sagte nahezu 1:1. Sicherlich muss man Anpassungen vornehmen. Aber die restliche Struktur kann man 1:1 übernehmen.

Bspw. für ein Wendeverbot für LKW von 9-12

type=restriction
restriction=no_u_turn
valid=no
hgv=valid
if:time=09:00-12:00

aighes wrote:

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.

Ich sehe die Gefahr der Verwirrung viel eher gegeben, wenn Tags in einem anderen Kontext etwas "so ähnliches", aber nicht genau dasselbe bedeuten.

Du hast die max*-Tags genannt. Wie würde man denn z.B. maxweight verwenden, um "Abbiegeverbot für Fahrzeuge über 10 t" auszudrücken?

type=restriction
restriction=no_u_turn
valid=no
hgv=valid
if:time=09:00-12:00

Und noch eine Frage: Wie drückst du "Abbiegen verboten, Anlieger frei" aus, wenn du den Wert der access-artigen Tags mit "valid" belegst?