Komplexe Parkgebühren

Hallo,
wie erfasst man komplexe Parkgebühren (key:charge)?

  1. Stunde kostenlos (ist mir klar: fee:contitional = no @ (stay < 1 hour)
    bis 2 Stunden: 1€
    bis 3 Stunden: 1,50€
    bis 4 Stunden: 2€
    ab 4 Stunden: 6€ (für die ersten Tag)
    für jeden weiteren Tag: 3€

Moie!

Hört sich an, als ginge es um ein Flughafen-Parkhaus oder so was?

Hab mal bei taginfo geschaut - der Ansatz charge:conditional=* scheint gut, ich hab’ aber nicht weiter geforscht, wie man

eintragen könnte.

So wie ich OSM bisher kennengelernt habe, findet sich aber auch dafür noch hinten unten rechts in einem wiki-Unter-Beitrag eine brauchbare Lösung… :wink:

Für mich geht das in die Richtung:

*=Brain_1.0 :slight_smile:

Also ovale Murmel über dem Hals einschalten… Es klingt zwar etwas Plump, aber ich sehe bei solchen Geschichten die Grenzen eines sinnvollen und vor allem in Ansätzen auswertbaren Taggings erreicht… Die Frage ist dann auch: wie schnell ändert sich das? Wer beoachtet das regelmäßig? Wer ändert das?

Erfassbar für mich ist höchstens: erste Stunde kostenlos, darüberhinaus Knete! …mehr nicht… Gebühren ändern sich gerne mal so schnell, wie andere ihre Hemden wechseln…

Sven

4 Likes

Also ovale Murmel über dem Hals einschalten… Es klingt zwar etwas Plump,
aber ich sehe bei solchen Geschichten die Grenzen eines sinnvollen und
vor allem in Ansätzen auswertbaren Taggings erreicht…

Das geht mir in der Hälfte aller Taggingdiskussionen so. Der krampfhafte
Versuch, alles in Schemata zu pressen, kombiniert mit der diebischen
Freude, jetzt doch eine Öffnungszeitenregelung gefunden zu haben, für
die das Schema nicht mächtig genug ist - juhu, gleich mal ein Proposal
schreiben für Öffnungszeiten, die von der Mondphase abhängig sind, oder
für Eiscafes, die im Winter Pelzgeschäfte sind oder vegane Speisekarte
nur an Messetagen…

Die Frage ist dann
auch: wie schnell ändert sich das? Wer beoachtet das regelmäßig? Wer
ändert das?

Ja, genau. “Wie lange würde es dauern, bis jemand merkt, dass das, was
ich hier eintrage, nicht mehr stimmt”…

3 Likes

Simply is the best! :+1:

Aber ich spreche niemandem das Recht ab, dies selbst zu entscheiden, wenn jemand wie @SabineSW es genau wissen will… :wink:

Ihr habt ja recht, ich mache es wie bisher:
fee=yes,
fee:contitional = no @ (stay < 1 hour)

3 Likes

Euren Purismus in allen Ehren, aber es ist legitim sowas taggen zu wollen. Und es gibt Projekte und Mapper, die solche Daten - zumindest auf lokaler Ebene - auch auswerten und pflegen.

(In der Tat ändern sich Gebühren aber meist so oft, das man sie auch mMn nur taggen sollte, wenn man nen Anwendungsfall dafür hat oder sich zutraut, die Daten zukünftig zu pflegen…)

Aber damit dieser Thread auch eine Lösung zur aufgeworfenen Frage vorschlägt: Mir fällt keine einfachere Variante ein als:

fee=yes
fee:conditional=no @ (stay<1 hour)
charge:conditional=3.00 EUR/day @ (stay>1 day); 6.00 EUR @ (stay<=1 day); 2.00 EUR @ (stay<=4 hours); 1.50 EUR @ (stay<=3 hours); 1.00 EUR @ (stay<=2 hours)

(ohne Gewähr - bestimmt findet jemand nen Logikfehler :slight_smile: ) Die verschiedenen durch Semikolon getrennten Bedingungen sind in “absteigender” Reihenfolge aufgeführt, damit die später genannten die vorherigen überschreiben.

Edit: Die conditional restrictions-Syntax sieht keine Leerzeichen vor und hinter den Operatoren (>, <, <= etc.) vor, nur vor und hinter dem “@”. Das betrifft auch das oben genannte fee:conditional=no @ (stay<1 hour).
Edit 2: Bei nochmaligem Lesen sind mir im Wiki auch Beispiele mit Leerzeichen um die Operatoren aufgefallen. Eine explizite Erwähnung dazu gibt es nicht. In der (automatisierten) Interpretation muss man also auch mit Leerzeichen vor und nach >, <, <= etc. rechnen.

1 Like

Irgendwann werde ich anfangen, überflüssige Kröpfe zu mappen :scream:

Ich werde schon eine Legitimation dafür finden.