Talk:Key:charge

Proposed advanced usage

• charge=[date][ - date][weekday][ - weekday][time][ - time] "amount currency"/"item";[additional dates, days, and times with different charges]

Date, weekday, and time describe when the charge is valid. The format should stick to the format in opening_hours=*.

Examples:

• charge = May-Oct: Mo-Sa 08:00-16:00 1.5 EUR/2 hour
• charge = 16 USD/hgv; 8 USD/motorhome; 6 USD/motorcar

In combination with opening hours, the time something is open, but has no charge given for this time, it is free (charge = 0). If it isn't free at any time, the mapper must provide charges for every opening time.

A more generic charge is overridden by a more specific charge. Example:

• charge = 10 EUR/person; 6 EUR/child; Su 16:00-24:00 4 EUR/child

This means, every person must pay 10€, children must pay 6€ except on Sunday since 16:00 o'clock. Then it is 4€ for children.

--MeastroGlanz 10:20, 17 April 2017 (UTC)

The above proposal was moved here from the wiki page. It conflicts with current tagging guidelines, and it is unclear if it is still relevant. --JeroenHoek (talk) 16:16, 16 May 2021 (UTC)

@JeroenHoek and MeastroGlanz: This proposed syntax also came up in the discussion about osmchangeset:115231332 after it was recently restored to the article. The access-as-unit usage appears to be endemic to Brazil and Malaysia but with low enough usage that it doesn't need to be codified here if it's problematic. I would tend to agree with the warning box. In the spirit of Proposed features/Parking lane conditionals, we should be transitioning to conditional tagging to the extent possible. The / operator should only be used for expressions of rates, for consistency with Map features/Units. Most likely the access-as-unit syntax was coined with the idea that someone pays "per motorcar", but this key is normally used for things like amenity=parking and highway=toll_gantry in which we're describing requirements for a driver inside the vehicle. A charge "per motorcar" would only maybe make sense on the very unlikely shop=car or industrial=auto_wrecker that charges a flat rate per vehicle. – Minh Nguyễn ^💬 20:47, 26 December 2021 (UTC)

Go ahead and draft a proposal. I only documented the actual use of the tag (mostly to clarify the difference between it and fee=* and fill some gaps in the documentation). In lieu of an accepted proposal that's the limit of what we can do here on the wiki with an in use tag like this. I didn't restore the above proposal though (which includes opening hours; already solvable via conditional restrictions), only the per unit pricing part. --JeroenHoek (talk) 16:42, 30 December 2021 (UTC)

ISO 4217

I think we should recommend to use the three letter ISO 4217 standard currency codes (https://en.wikipedia.org/wiki/ISO_4217) instead of the one unicode characters. So $ should be USD, € should be EUR, etc. Many currencies don't have character symbols at all.

Also we should expect to have a space between the amount and the currency code.

Amount should be used in US format, so using . (full stop) as the decimal mark to separate the integer and fractional parts.
Apostrophe ' would be optional to separate thousands.

So the examples would look like:
charge=May - October Mo - Sa 8:00 - 16:00 1.5 EUR/2h
charge=16 USD/hgv; 8 USD/motorhome; 6 USD/motorcar
charge=4 USD/person/day; 12 USD/person/week; 0 USD/child < 14years
or
charge=1'000 USD/day
charge=10.25 EUR/adult

--AndrasFuchs

Agree. Please add your signature in future. --MeastroGlanz (talk) 11:34, 1 August 2017 (UTC)

Am I allowed to change the wiki page according to this or should I wait for confirmations from others? --AndrasFuchs (talk) 06:28, 2 August 2017 (UTC)

I agree with three letter currency codes.
I think the currency code should be before the amount, as that is the custom in BrE (which is OSM convention) and apparently widely used
If we're following conventions, might as well follow SI convention: dot for decimal separator (because BrE) and space for thousands.
Finally, I think subkeys would be more appropriate for certain types of fees, something like a specific format for toll booths (in response to charge=16 USD/hgv; 8 USD/motorhome; 6 USD/motorcar)
--Tqdv (talk) 09:52, 7 January 2018 (UTC)

I agree with three letters (just because $ is used not only for USD), agree with "." (it used anywhere), and totally disagree with apostrophe (looks as feet) - don't do unnecessary formatting. And I have no idea what for is the space between the amount and letters (and some other spaces). Format of period is described in opening_hours=*: May-Oct Mo-Sa 08:00-16:00 VlIvYur (talk) 21:58, 20 March 2019 (UTC)

Conditional restrictions

Now that Conditional restrictions exist and are widely used for other keys already, time-based price differences should probably be expressed using that syntax rather the one suggested in "Proposed advanced usage". That is, the older example would use like this instead:

 charge:conditional = 1.5€/2h @ (May-Oct: Mo-Sa 08:00-16:00)

--Tordanik 20:34, 29 August 2019 (UTC)

If we attempt to follow formally established formats, per maxstay=* from Proposed features/Maximum Stay, the time rate unit should use charge=1.5 EUR/1 hour and charge=1.5 EUR/2 hours (plural noun form instead of singular adjective form). --Kovposch (talk) 14:28, 2 March 2021 (UTC)

Conditional charge for museum card?

If something like charge=7.50 EUR represents the default price, usually for adults, then it would make sense to use *:conditional=* for other categories. Is there an established way to:

• Tag prices for children?
• Tag prices (or the absence of a charge) for people carrying something like the Dutch Museumkaart which grants free access to many museums?
• Tag both of the above?

--JeroenHoek (talk) 20:55, 8 May 2021 (UTC)

1. In theory, charge:conditional = 4 EUR @ (age<=12) if max_age=* and min_age=* is supported, but no way of making sure this.
2. Having the Museumkaart may already be considered as having "bought" the tickets. How about eg network=Museumkaart?

---- Kovposch (talk) 05:19, 9 May 2021 (UTC)

Good suggestion for the age, that makes complete sense. Thinking about the Museumkaart as a way to 'purchase' tickets makes me think I could consider something like payment:museumkaart=* for this. Thanks for pointing me in the that direction. --JeroenHoek (talk) 06:01, 9 May 2021 (UTC)

Decimals?

The documentation reads:

The amount charged should include cents (or the currency equivalent) even when there are none […]

This seems unnecessarily restrictive. The Japanese Yen and Korean Won for example don't even use decimal places. And something like 1 EUR doesn't strike me as problematic either.

Does anyone know why this restriction was placed on this tag? --JeroenHoek (talk) 08:25, 10 May 2021 (UTC)

@Blackboxlogic: I think you added this restriction to the page. Is that right? --JeroenHoek (talk) 08:28, 10 May 2021 (UTC)

That was me. I believe it followed a conversation on slack #tagging which probably included mostly American voices. I realize now that the phrasing I used is ambiguous, and I wonder if rewording it would address your concerns. "Even if none (cents) exist" was intended to describe the amount, not the currency. For cases where the price is a round number but the currency has cents (or equivalent) still end with .00 . For cases when the currency has no "cents", don't. Said another way: always express the value maintaining the maximum precision for the currency. Blackboxlogic (talk) 11:48, 10 May 2021 (UTC)

I see, thanks. If 100 JPY is fine because Yen doesn't have cents, then 1 EUR should be fine and equivalent to 1.00 EUR. I can't see a reason to keep that restriction though, because data consumers will already have to handle missing decimals right? On the other hand, it does inconvenience mappers because a lot of charges are in whole Dollars, Euros, or Pounds. Am I overlooking something? --JeroenHoek (talk) 11:54, 10 May 2021 (UTC)

I see the "unnecessary" decimals as a valuable record of precision. For arguments sake, I'm going to use another tag as an example: width. A highway with 'width=16 m' is somewhere between 15.51 and 16.5, and I acknowledge that I rounded the number by NOT including decimals. 'width=15.00 m' indicates that my measurement is accurate to the centimeter, and it's somewhere between 14.995 and 15.0049 . Back to currency... I think it's common (or at least, not uncommon) for a mapper to see $2.95 and tag it 'charge=3 USD', and they aren't wrong and the information they provided was useful as long as the data consumer doesn't assume higher precision. That's easier to type but has lower precision so I'm not going to /encourage/ it. Yes, data consumers will need to handle values without cents. Including .00 allowes them to confidently interpret those values by also understanding precision, if they choose. Blackboxlogic (talk) 12:21, 10 May 2021 (UTC)

Well, yeah you are correct about the precision, but height=2 is completely valid. But I think I see what you mean about the rounding up or down. I've changed the text to clarify this. How does that look? I understand wishing to force mappers to be very precise, but this does not match actual use and seems unnecessary in this case. The thing about precision in measurements is that you do have varying degrees of accuracy, but for an amount of money there is just one value (either with or without cents). For Dollars this means a precision of two places beyond the period, with the strong convention that $2 means $2.00. --JeroenHoek (talk) 12:36, 10 May 2021 (UTC)

Regarding "a fee of €3 may be written as either 3 EUR or 3.00 EUR" I would at least add ", though 3.00 EUR is preferred to indicate that the value hasn't been rounded."

I'm concerned that "written as either 3 or 3.00" implies that they are equivalent, when they indicate different levels of precision. It acknowledges that rounding sometimes happens, and here is the way to indicate that it hasn't. I think this would be good information for importers and data consumers. Blackboxlogic (talk) 14:43, 10 May 2021 (UTC)

I understand your position, but I'm doubtful that this is a preferred notation for a majority of mappers, so I would be hesitant to explicitly recommend it — especially given existing usage (see charge=* and search for USD or EUR). I must say that I have never seen mappers actually round sums that contain cents either. I've added your reason for that preference to the text though. --JeroenHoek (talk) 15:13, 10 May 2021 (UTC)

Move 'proposed advanced usage' to talk page

This wiki page currently has a section Proposed advanced usage which clashes with existing tags (see the big red warning box). If there are no strenuous objections I would like to move that section to this talk page instead. It should at this point either become a full fledged proposal or be abandoned, because it is in conflict with *:conditional=*, and no makes the documentation more confusing than it should be. --JeroenHoek (talk) 11:38, 11 May 2021 (UTC)

I've made the bold edit to move that section here. I'm not against expanding the tagging, but a proposal to do shouldn't be part of the article itself. --JeroenHoek (talk) 16:16, 16 May 2021 (UTC)

Complex pricing rules

In some cases pricing rules are too complex (IMO) to express with conditionals (e.g. discounts for repeated usage, subscriptions, discounts during the last hour of weather-dependent opening hours, etc.). In some cases there's a web page that describes the rules. An example of such a ruleset is https://www.stadt-zuerich.ch/ssd/de/index/sport/schwimmen/Preise.html (it has discounts for repeated usage and subscriptions).

First and foremost, should one specify `charge` to be the charge in the "standard" case, or not specify it at all?

Secondly, how should one specify where the precise rules can be found? `source:charge` might work, except if we answered the previous question in the negative (it seems unexpected to place `source:charge` on a node without a `charge`), but it gives no indication that one can find _more precise_ information there. Maybe a new tag (e.g. `charge:url`) would make sense?

Robryk (talk) 15:24, 31 July 2021 (UTC)

I think listing only the common charge is fine if that covers the vast majority of cases, or you can omit it altogether. Including a link to the website showing all the pricing information can be useful. website=* is already documented as having the potential to be used as a namespace (examples shown include website:booking=*), so I would consider website:charge=*. Of course this should be in addition to a generic website=*. --JeroenHoek (talk) 15:32, 31 July 2021 (UTC)

Key:website doesn't have a good example section. First and foremost, booking=* doesn't conform with the pre-existing reservation=*. I'm going to list out the alternatives by editing there. ---- Kovposch (talk) 22:40, 31 July 2021 (UTC)

charge:url=* is good. I'm used to reading about opening_hours:url=*. ---- Kovposch (talk) 22:40, 31 July 2021 (UTC)

Charge relation for toll road sections

Has anyone used a relation to mark the differing charges along a toll road based on varying entry/exit locations? I was thinking members with role=from, role=to on the toll gantries and you'd need one relation for each combination. --Aharvey (talk) 10:40, 17 August 2022 (UTC)

That seems too complicated. What is the toll system like? Toll rate is easier. --- Kovposch (talk) 03:45, 18 August 2022 (UTC)

Currency abbreviated?

Usually we discourage the use of abbreviations, why are we encouraging here the alphanumeric abbreviations rather than the official symbols and names? —Dieterdreist (talk) 18:36, 29 December 2022 (UTC)

It is an ISO standard. Same in currency=*; or name:*=* and language=* .
Secondarily, it is not convenient to type symbols, or spell their names.
--- Kovposch (talk) 07:05, 30 December 2022 (UTC)

Implication of variable rates and exemption periods charged later

A question was asked elsewhere, and an example raised in Conditional_restrictions#Pricing after an initial answer.

Photo	Tagging	Interpretation
	charge=2 MYR/hour charge:conditional=1 MYR/hour @ (stay > 1 hours) fee=no fee:conditional=yes @ (09:00-17:00); no @ (customers AND stay < 1 hours))	Parking is generally for free, but between 9 AM and 5 PM you have to pay 2 Ringgit for the first hour and 1 Ringgit for every following hour, though customers can skip the first hour charge.

Although this is a common situation, there is a particularly critical interpretation issue I noticed, aside from 2 other less severe one: The meaning of this becomes you are charged a lower $1/hr for the total time when staying longer than 1hr, not using $2 for the 1st hour. Besides, customers are charged $1 for the 1st hour if they stay longer.

This would be a shortcoming in the syntax of charge=* not allowing combinations of fixed and per-unit prices by a sum, or periods (ie piecewise definition in math terms); aside from other possible deficits. (Since another deeper problem is whether units are divisible, or rounded-up for parking less than 1hr being counted as 1hr; this may be assumed for some units viz time here, but not others eg volume) It's not possible to calculate a composite rate either, as this is changing.

The 2nd issue is whether fee=* should change to *=no when there is an exemption period that will be charged eventually, ie if you stay longer here. While this situation may not appear to be a problem, the significance arises for the case in reverse: Some initial hours is paid, with a cut-off, or later hours becoming free. fee:conditional=no @ (stay > * hours} won't make sense, when it is in fact fee=yes as you already payed earlier. (Sorry I can't find the example I have discussed before yet)

So I suggest this interim solution, after fixing the 3rd issue concerning the default.

Photo	Tagging	Interpretation
	charge=2 MYR/1 hour; 1 MYR/hour charge:conditional=(0 MYR/1 hour; 1 MYR/hour) @ (customers) fee=yes fee:conditional=no @ (17:00-09:00)	Between 9 AM and 5 PM, you have to pay 2 Ringgit for the first hour and 1 Ringgit for every following hour, though customers can skip the first hour charge. Parking at other times at free.

Using semicolon-delimited multivalue is a generally acceptable syntax. The reason for this time unit is charge=2 MYR; 1 MYR/hour should be used if the situation is instead $2 fixed + $1 for every hour including 1st. The exemption period is moved inside, as it has to be accounted for the total. and allows for consistency with the reverse case.

This method would be usable in other cases. Eg something with a $100 + $10/person price could be {{tag|charge
A check on https://taginfo.openstreetmap.org/keys/charge#values only reveals a lot of semicolon uses can be converted into modal suffix (eg charge:motorcycle=* + charge:hgv=*/axle), or conditions (with "child" converted to age when known). The example of charge=0.50€/h; 3.00€/d depends on the exact meaning, aside from the currency symbol that can be corrected.
Overall, I still feel charge=* needs more comprehensive consideration and specification.
--- Kovposch (talk) 12:09, 6 January 2023 (UTC)

Ok I noticed a 4th point that should be specified. This doesn't need to be simply *:conditional=* @ (customers) when there is a criteria.

Photo	Tagging	Interpretation
	charge=2 MYR/1 hour; 1 MYR/hour charge:conditional=(0 MYR/1 hour; 1 MYR/hour) @ (customers) customers:conditional=Lintas Superstore @ (charge >= MYR 10) fee=yes fee:conditional=no @ (17:00-09:00)	Between 9 AM and 5 PM, you have to pay 2 Ringgit for the first hour and 1 Ringgit for every following hour, though customers can skip the first hour charge. Parking at other times at free.

Neither a min_charge=* nor charge:conditional=(0 MYR/1 hour; 1 MYR/hour) @ (charge >=10) and charge:conditional=(0 MYR/1 hour; 1 MYR/hour) @ (customers AND charge >=10) can be used, as charge=* on this object refers to the amenity=parking, not business. --- Kovposch (talk) 12:33, 6 January 2023 (UTC)

@Hike&Map: --- Kovposch (talk) 21:39, 7 January 2023 (UTC)

Surcharges

I've been using percentage values for a while in practice and my tagging guide at User:Aharvey/charges seems to be working well, so might be time to document this as part of this page? --Aharvey (talk) 04:06, 17 September 2024 (UTC)

Thought it's time to put this into a proposal now at Proposal:Surcharges and Discounts --Aharvey (talk) 05:39, 17 September 2024 (UTC)