Talk:Key:charge

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)


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 TagInfo 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)