Ich vermute die “;” - probiere es einmal nur mit Leerzeichen.
JOSM meckert öfters - > https://forum.openstreetmap.org/viewtopic.php?pid=698612#p698612 M.E. ist es richtig wenn “falsches” angezeigt wird. Es sollte dann aber möglich sein etwas als “richtig” zu markieren. Das Ignorieren der Fehler ist auch nicht der beste Weg.
EDIT: oder “;” ohne LEERzeichen - dann kann man wenigsten erkennen, was der Validator möchte.
Das würde dem Wiki-Beispiel >> access:conditional=delivery @ (07:00-11:00); customer @ (07:00-17:00) << widersprechen!
Ich vermute, daß der JOSM-Validator hier eben einen falschen Fehler anzeigt.
; ist zwar ein Element der conditional-access Grammatik und wenn auch zulässig im restriction-value Teil, so ist entweder der Parser von JOSM verwirrt oder JOSM spielt wiedermal den Lehrmeister (mein Parser hat kein Problem damit). So oder so ein “Fehler” ist es nicht, soweit man überhaupt der Meinung ist, dass Aufzählungen von mehreren access-Werten zulässig sind.
Von der Grammatik her gehen alle 3 Versionen. Von der Semantik sind 2 und 2 unklar (die OH Spezifikationen sind in diesem Fall übrigens gleichwertig), sprich bei Access für Fahrzeuge ist die Kombination von no mit was anderen sinnfrei, dass hat allerding mit conditional access nicht wirklich was zu tun.
Dann bräuchten wir wohl eine neue und genauere Definition der Syntax, die erste Version ist im Augenblick nicht dabei im Wiki. Die Auswertung wäre aber wohl immer eindeutig möglich.
Ich war schon ein paar mal kurz davor das ganze mal richtig zu dokumentieren (so sind z.B. aktuell geschachtelte Klammern im condition Teil erlaubt, obwohl nutzlos, des weiteren müsste man die möglichen condition-Werte mal aufzählen und dokumentieren).
Aber zurück zum spezifischen Problem, ; ist im restriction-value Teil nach Wiki nicht verboten (im Gegensatz dazu darf es ohne Klammern im condition-Teil nicht vorkommen) und ist auch eindeutig parse-bar. Da @ vorkommen muss ist der restriction-value alles zwischen dem Trenn-; und dem @. Könnt man auch anders machen, bräuchte aber dann irgendein escape-Mechanismus für ; im restriction-value.
Mir gefällt ja der Vorschlag den restriction-value einfach auch in Klammern zu setzen (optional, wenn mehrere Werte vorkommen), damit ist es eindeutig zusammengefasst, sowohl vom Parsen als auch vom reinen menschlichen Lesen her:
Dort am way hängt momentan noch folgendes Merkmal/Attribut dran:
traffic_sign=DE:260**;DE:1020-30;**DE:1026-38
Laut wiki [1] werden aber - falls ich das richtig verstehe - die aufgelisteten Zusatzschilder mit “,” Komma anstatt wie hier mit “;” Semikolon getrennt…
Nebenbei, gibt es Software die bereits heutzutage das traffic_sign=* (am Weg oder am Knoten neben der Strasse der den physischen Standorts des Verkehrszeichens darstellt) auswerten?
(so sind z.B. aktuell geschachtelte Klammern im condition Teil erlaubt, obwohl nutzlos, des weiteren müsste man die möglichen condition-Werte mal aufzählen und dokumentieren).