[talk-ch] Taggen von Blauen Zonen (Parkplätze)

[Raphael Das Gupta (das-g)]

On 26.06.22 17:16, Danilo wrote:
>> 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:

  * (1) Grundsätzlich (d.h., falls keine spezifischere Regel
    entgegensteht) keine Gebühr (fee=*no*), /aber/ (fee:conditional=…):
      o (a) Zu den Zeiten, in denen die Parkzeit beschränkt wäre, doch
        eine Gebühr (*yes*@(Mo-Sa 08:00-11:30,13:30-18:00; PH off))³, …
      o (b) … ausser, wenn man kürzer als 1h² parkt (*no*@(stay < 1h)) …
      o (c) … oder ein Abo (oder sonstige Genehmigung) hat
        (*no*@permit_holder).

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 at permit_holder; no@(stay < 1h); no at 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 at permit_holder; no@(stay < 1h); no at 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
<https://pk19.ch/informatiker-efz/>) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20220627/7bc30415/attachment.htm>