Imagine a public swimming pool charges 6€ for adults and 3€ for children, elderly and disabled. How would you tag that? Like so?
fee = yes
charge = 6 EUR
charge:conditional = 3 EUR @ age<16 AND age>63 AND disabled=yes
The age tag is only used for trees as of now.
max_age could be - a worse - alternative to age.
It seems there is a majority of people who dislike having information like this in OSM, prices tend to change often and are of limited use in a geospatial database.
However, your condition asks for people that are disabled seniors younger than 16. Formally correct would be
3 EUR @ age<16; 3 EUR @ age>63; 3 EUR @ disabled
‘age’ is correct here - it’s not a tag, but a property: we also use ‘weight’ in conditional restrictions, not ‘maxweight’.
couldn’t this be written more easily as
3 EUR @ (age<16;age>63;disabled)
maybe the disabled also as
charge:disabled=3 EUR
Thanks for the correction! That makes sense of course.
From that point of view, we shouldn’t be adding most POIs at all, since many of them change regularly. Yet after 20 years of OSM, it’s clear that there are plenty of dedicated contributors who work hard to keep this kind of information up to date - and I count myself among them. Personally, I find it very useful to tap on the POI of a museum, for example, and immediately see the current entrance fee.
That looks like the cleanest solution to me!
In some cases the rules for reduced entrance fees can get rather complicated, e.g. children up to 16 years AND students up to 25 years. In those cases a simplified tagging might be a good solution. For example:
charge:discounted = 3 EUR
That doesn’t look like it is correct according to the documented grammar Conditional restrictions - OpenStreetMap Wiki There is currently no way to express a logical “OR” at a condition level.
See above @dieterdreist is probably confusing things with the use of opening hour expressions in conditions.
Please don’t. Adding arbitrary subkeys on keys that are not defined for that like e.g. ‘payment:’ makes using the data much more complicated
Apart from being a new subkey, this value doesn’t add any useful information, because one would still have to check who exactly counts as “discounted”. IMO that’s too broad a classification to be useful.
charge:discounted= looks to me it’s the charge:*= when *:discounted= cf discount= , ie adult discounts. What’s the problem with categorizing them as student, or best separating child and student?
As payment:*= is mentioned, if charge= means adult, it could be charge:others= (but needs charge:adult= according to payment:others= use)
First of all unlike the above focusing on prices, my doubt on this is defining the age groups by age only in conditions. It’s not “very useful to tap on the POI of a museum, for example, and immediately see the current entrance fee.” with ages only, when the age group is named first, with the age bracketed or in small text.
charge= has its own syntax with units for better or worse, unlike *:conditional= on access= and roads. It would be eg charge=6 EUR; 3 EUR/<16_years_old; 3 EUR/>63_years_old; 3 EUR/disabled to define it inline.
It would be better to keep age grouping, to separate prices and age definitions, eg charge=6 EUR; 3 EUR/child; 3 EUR/senior; 3 EUR/disabled + child:max_age=16 + senior:min_age=63
In some cases the rules for reduced entrance fees can get rather complicated, e.g. children up to 16 years AND students up to 25 years. In those cases a simplified tagging might be a good solution. For example:
charge:discounted = 3 EUR
when it gets really complicated is when different discounts for different kinds of club or association memberships, company employees, ministry members, residents, etc. are available, the lists can fill several screens on websites, not uncommon in Italy.
We don’t typically add all these exemptions, e.g. for press, teachers, university members of certain faculties, tour guides, etc.
IMHO The by far best option for non-trivial cases is to link to a proper list of fees, using charge:url.