Es ist nicht wahr, dass man da für länger nicht parkieren darf: man kann doch ein Abo oder ein Tageskarte besitzen.Ja, das stimmt. Wie verbreitet sind denn solche Conditionals? Der Vorschlag ist zwar korrekt aber doch extrem komplex auszuwerten. Die Tools, welche visualisieren / auswerten, werden wohl zu einem Grossteil einfach "fee=yes" sehen und den Parkplatz als kostenpflichtig (aber ohne Maximale Verbleibdauer) markieren, nicht? Gibt es irgendwelche verbreiteten "Parking-Maps" oder ähnliches, wo man sieht wie das in der Praxis umgesetzt wird? Für mich ist die Blaue Zone primär eine Gratisparkmöglichkeit mit Zeitlimitierung, mit der Zusatzmöglichkeit von Genehmigungen / Tageskarten. Kann man das vielleicht entsprechend nicht-invertiert im Tagging umsetzen? Mir fällt leider auch nichts ein, aber vielleicht hat sonst jemand eine Idee...
Ich wäre auch für ein nicht-Invertiertes Tagging, da das dem
entspricht, wie die Blaue-Zone-Bedingungen i.d.R. Menschen
kommuniziert werden.¹ Den Fallback-Wert für den Fall, dass keine
Condition zutrifft, sollte man laut
https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Default_restrictions
nach Möglichkeit sowieso explizit angeben, wie das Roberts
Vorschlag schon macht. Diesen Default-Wert und die Restrictions
samt ihren Bedingungen können wir natürlich umdrehen, um das selbe
Ergebnis zu erreichen. Ungefähr so² sollte es gehen:
fee=no fee:conditional=yes@(Mo-Sa 08:00-11:30,13:30-18:00;PH off); no@(stay < 1h); no@permit_holder charge=15 CHF/day …
Zu lesen als:
In natürlicher Sprache würde man (a) und (b) evtl. in der Reihenfolge vertauschen, das würde für OSM-Conditional-Restrictions aber eine Verkomplizierung durch boolsche Operatoren erfordern. In der vorliegenden Reihenfolge können wir die "letzte zutreffende Condition gewinnt"-Regel aus https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Evaluation_of_conflicting_restrictions nutzen:
In case of multiple matching value-condition pairs in the same tag the last matching value becomes the effective restriction value. Therefore it is important to put the more general restriction first and the more specific restriction last.
¹Die Öffnungszeiten-Syntax, die einen Teil der Conditional-Restrictions-Grammatik bildet, erlaubt u.A. deswegen mehrere Varianten das semantisch gleiche auszudrücken, damit vorgefundene Angaben durch Mapper ohne allzu komplexe Konvertierung übernommen werden können. Die Bürde der (wenn auch wohldefinierten) Interpretation oder einer Normalisierung wird damit den OSM-Datenkonsumenten auferlegt, wobei primäre OSM-Datenkonsumenten, die als Vorverarbeiter für nachgelagerte OSM-Datenkonsumenten agieren, letzteren diese Arbeit natürlich abnehmen können (oder stattdessen die Bürde an jene weiterreichen).
²Die Information, dass zwecks Parkzeitdauer-Ermittlung die (aufgerundete) Park-Beginnzeit per Parkscheibe zu indizieren ist, fehlt hier allerdings noch. Da Automobilisten aber normalerweise eine Parkscheibe mitführen und vor Ort dann sowieso die Beschilderung & Verkehrsregeln beachten sollten, um ordnungsgemäss zu parken, ist das aber vermutlich nur beschränkte relevant und muss nicht unbedingt in OSM abgebildet werden. Die schon für die Parkplatz-Auswahl (und damit: schon, bevor man vor Ort ist) relevanten Kriterien wären von den vorgeschlagenen Tags ja abgedeckt.
³Die Handhabung von Feiertagen habe ich hier in die allgemeine
Zeitbedingung integriert (PH off),
so dass uns eine separate Bedingung hierfür erspart bleibt (und
die Interpretation der Zeitbedingungs-Angabe eindeutig ist).
Zu deinem Vorschlag (den ich sonst abgesehen von der Komplexität gut finde):fee:conditional=no@permit_holder; no@(stay < 1h); no@Su,PH; no@(Mo-Sa 11:30-13:30,18:00-08:00)Die wrappende Zeit (18:00-08:00) finde ich etwas heikel, das kann schnell mal falsch als "Montag 11:30 bis Sonntag 08:00" interpretiert werden.
Die korrekte (wenn auch hier von Robert nicht intendierte)
Interpretation von "Mo-Sa 11:30-13:30,18:00-08:00" wäre: Montags
bis Samstags jeweils sowohl Mittags von halb zwölf bis halb zwei
als auch ab sechs Uhr abends bis (folgetags) 8 Uhr morgens.
Das ist von
https://wiki.openstreetmap.org/wiki/Key:opening_hours#Closing_after_midnight
so beschrieben und von
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:extended_hour_minutes
so spezifiziert und kann mit
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Sa%2011%3A30-13%3A30%2C18%3A00-08%3A00
ausgetestet werden.
Hier spricht vielleicht der Softwareentwickler aus mir, aber sollte man das villeicht besser auf die unmissverständliche Art taggen? fee:conditional=no@permit_holder; no@(stay < 1h); no@Su,PH; no@(Mo-Sa 00:00-08:00,11:30-13:30,18:00-00:00)
Das wäre eine korrekte Art das anzugeben, aber die
nicht-invertierte Variante ist m.M.n. viel einfacher (sowohl zu
schreiben als auch zu lesen/verstehen).
Bisher wurden in Zürich anscheinend noch praktisch keine Blauen Zonen mit Beschränkungen gemappt. Ich habe kurz gesucht und einige mit "note=blaue zone" gefunden, aber nichts, was die effektiven Rechte genau taggt. Meine Theorie: Die Conditionals sind so komplex, dass praktisch niemand weiss, wie sie anzuwenden sind 😜 (Aber wir kommen wohl nicht um sie drum herum, weil die Realität ebenfalls komplex ist.)
Im Gegensatz zur Opening-Hours-Syntax (die in OSM für mehr als nur Öffnungszeiten gebraucht werden kann und wird) sind für die Opening-Hours-Syntax glaub' noch keine Parser/Interpreter verfügbar. Das dürfte sich bald ändern, denn ich liess am IFS Institut für Software in einer IMS-Praktikanten-Abschlussarbeit (IPA) einen solchen Parser und Interpreter implementieren, den wir als FLOSS zu veröffentlichen gedenken. Ich hoffe, dass sich dieser für die OSM-Community als brauchbar erweisen wird, auch wenn er als Haskell-Library umgesetzt wurde. (Diese Programmiersprache ist im OSM-Umfeld m.W. bislang nicht gross in Verwendung, eignet sich für Parsing-Aufgaben aber bestens.) Bislang unterstützt er bzgl. der Opening-Hours-Syntax, die Teil der Conditional-Restrictions-Grammatik ist, erst einen Teil der Spezifikation, sollte sich aber gut auf eine vollständige Unterstützung ausbauen lassen.
Herzliche Grüsse,
Raphael