Proposal talk:Surcharges and Discounts

No advantage in mixing, only troubles

Moved to Proposal_talk:Surcharges_and_Discounts#General_caseKovposch (talk) 04:31, 23 September 2024 (UTC)

I don't find extending charge=* directly to be a good idea. Separating them is clearer and cleaner. Eg charge:modifier=* to borrow the modifier=* meaning, if surcharge and discount are to be expressed together.

1. charge:conditional=* could already be very long. It's unneeded to further extend it to risk hitting the 255char length limit.
2. charge:*=* can be interpreted as the price to be paid by that method. This is seen from the 449 charge:sunpass=* + (-9) charge:sunpass:conditional=* , and 89 charge:ntta=* + charge:ntta:conditional=* . The number not insignificant for a less commonly added fine detail. Relying on signs or percent symbol is not totally reliable either, prone to typos.
3. *:conditional=* is technically evaluated by order, and charge:*=* by modes. You can't provide 2 piece of information at the same time. Eg software is only expected to parse charge=10 AUD + charge:conditional=10% @ (Su) + charge:credit_cards=1.5% to show 10% on Sunday, or 1.5% if you selected credit cards. The variant overrides the default. They can't depend on each other.
4. charge:*=* suffix is already used by access:*=* modes. Having both vehicle modes, and payment methods, adds to the complexity.

Specific format problems:

• charge:*=10% : Unsigned percentage looks confusing as to whether it means 10% of original price, ie 90% off. When the surcharge is higher (eg to differentiate tourists), charge:*=50% is ambigious to the extreme as to whether it means half price, or 150%. In some languages, discounts as expressed as percentage of original price, adding to their misunderstanding.
• charge:*=no : It's not good practice to mix 2 different data types together. That's not very organized and clean. Again, charge:*=no is confusing whether it is a mistake of adding it's free.
• charge:*=yes : Resembles a mistake of fee:*=yes .

As a whole, charge=* already has a problem of using access:*=* modes in the unit ( most numerous seems to be BRL/motorcar from Brazil), which is better moved to the aforementioned suffixing by standard. Further complicating it doesn't help to improve the mess.
—— Kovposch (talk) 07:45, 17 September 2024 (UTC)

Do you have a better suggestion? I've added a column to the examples on the proposal to use payment:<method>:fee=yes/no and payment:<method>:charge=* to specify an exact charge to use a particular payment method (on top of the charge=*, but beyond this I'm not sure what you're suggesting as alternatives for the rest. --Aharvey (talk) 12:10, 17 September 2024 (UTC)

Can't think of something that will solve both nicely yet. I will simply list what I looked through.

• *:discount=*
  • fuel:discount=* : Has defects that need to be sorted out anyway
    • Contradicts fuel:*=* meaning
    • Lack of yes/no option
    • mixing data types)
  • A few owncup:discount=* , reusable_packaging:discount=* , and takeaway:discount=*
• discount:*=* : discount:citycard=* , discount:students=* , etc

These were discussed last month https://community.openstreetmap.org/t/discounts-tagging/117607/
They need to be taken into account. There's some demand in them.
General surcharge is tricky. Can't apply the payment:*:charge=* solution to it.
—— Kovposch (talk) 17:11, 19 September 2024 (UTC)

Should be coherent with already in use tags

There are already about 150 tags like payment:debit_cards:min_payment=* to tag a minimum amount necessary to use this payment method and about 1000 payment:coins:denominations=*. I'd prefer if these and the new charge tags would use a coherent syntax. payment:debit_cards:charge=* seems better suited, because it keeps all payment related tags in one namespace and is easier to distinguish from charges for the primary service offered by the POI. --Mueschel (talk) 07:47, 17 September 2024 (UTC)

Yes, I suggested to put yes/no in payment:*:fee=* , thus the exact amount in payment:*:charge=* Talk:Key:payment:*#*=surcharge
—— Kovposch (talk) 07:55, 17 September 2024 (UTC)

I think payment:<method>:fee=yes/no would also work.If using payment:*:charge=* though would that mean you have a syntax for values of charge=* and a different syntax for values of payment:<method>:charge=*, since currently charge=* only accepts exact values but a surcharge may be an exact value or a percentage values. Maybe that's okay? --Aharvey (talk) 11:30, 17 September 2024 (UTC)

Procedure-wise, key:charge is only "in use" for some reason. Should at least be "de facto" before you propose something for it. This can be taken as an opportunity to extend it.
I would like to see charge=*/hgv replaced by charge:hgv=* etc. There's already charge=*/hgv/axle that doesn't fit the format.
—— Kovposch (talk) 17:08, 19 September 2024 (UTC)

happy_hours

happy_hours=* Bkil (talk) 11:53, 17 September 2024 (UTC)

I've added this to the see also thanks. Aharvey (talk) 23:57, 17 September 2024 (UTC)

Resolved

Loyalty schemes

fuel:discount=* [1]] Bkil (talk) 11:54, 17 September 2024 (UTC)

I feel this one could be a more general "which loyalty cards" are accepted here kind of tagging, similar to payment:*=*, you could have loyalty:*=*. I see this as separate this this proposal. --Aharvey (talk) 05:16, 22 September 2024 (UTC)

It's less than clear cut. Indeed you can collect points on your (single-corporation) loyalty card and spend from it. However, certain places offer a fixed 10% discount just for showing up a loyalty card. This is also the main point of membership-based coalition based loyalty programs where you can purchase for a 10% discount at any partner as long as you show your membership card. [2] Bkil (talk) 10:05, 22 September 2024 (UTC)

Discount to students or office workers in the same building

Some cafe and fast food place offers a discount to any student showing their government issued ID. Others provide a discount to workers from the same building possibly by showing their building entrance pass badge. Neither of these are considered specific loyalty cards that one must register separately. Bkil (talk) 11:55, 17 September 2024 (UTC)

Discount to debit cards from certain issuer banks

Certain fast food places offer a discount to you if the debit card you pay with is issued by a given bank. (MagNet in this specific case) How will you tag these? Bkil (talk) 16:27, 17 September 2024 (UTC)

Under my original proposal here this is well defined, similar to the credit card surcharge it would be a credit card discount, also similar to the cash discount. charge:magnet=-5% for a 5% discount when paying with magnet. --Aharvey (talk) 05:18, 22 September 2024 (UTC)

Resolved

General case

payment:surcharge=* isn't a payment:*=* method. If a top-level surcharge=* is unwanted, it could be fee:surcharge=* or charge:surcharge=* .
I wanted to keep yes/no available for discount=* . It could have discount=customers (eg hotel guests at restaurants), discount=private (eg students of a certain school only that won't be described if discount:students=* used, employees), etc access=* when certain users can receive a discount. So the exact percentage could be eg discount:rate=* .
—— Kovposch (talk) 04:29, 23 September 2024 (UTC)

@Kovposch: Yeah I notice that iD will read payment:surcharge=* as "surcharge" being a payment type. In my original proposal I used charge=* with a positive value being a surcharge and a negative value being a discount. Perhaps I should go back to using charge=* or even surcharge=* + discount=*. Or even payment_surcharge=*. Aharvey (talk) 05:22, 27 May 2025 (UTC)

@Kovposch: I've updated the examples to show surcharge=* + discount=* I think that works. I might try again with the proposal based on this. Aharvey (talk) 21:55, 3 June 2025 (UTC)

Thinking about this more now, do applications have a problem with socket:*:*=* of socket:*:output=* , socket:*:voltage=* , and socket:*:currently=* ? Ideally, they should be fixed. I was only commenting about payment:discount=* , not payment:*:discount=* .
For the next preferred option, I would keep discount:payment:*=* in case anyone has more ideas about discount:*=* suffixing other than paying methods (as the range of different payment:*=* is quite a mess)
—— Kovposch (talk) 03:33, 4 July 2025 (UTC)

a bit too much

Note that this things are complex and change quite often.

While we have problem to collect opening_hours=* before they will get outdated.

Yes, we have ATYL but trying to collect this seems a bit too much Mateusz Konieczny (talk) 11:30, 7 October 2024 (UTC)

Thanks for your feedback. In my experience these change with about the same frequency as opening hours do, and are still infrequent enough to warrant collection and tagging in OSM. In terms of usefulness of the data I rate it as on par with opening hours. When deciding on which venue to visit, you usually want to know are they open, but also do they charge a surcharge today or not. Aharvey (talk) 01:58, 28 February 2025 (UTC)

Would it be cleaner and more maintainable to separate into discount:*=yes + discount:*:amount=10% similar to fee=yes + charge=1 AUD ? As currently used by discount:citycard=* and discount:students=*
—— Kovposch (talk) 03:41, 4 July 2025 (UTC)

You can at least add *=yes only, not specifying the amount. An outdated amount might still be useful to indicate the order-of-magnitude.
—— Kovposch (talk) 03:38, 4 July 2025 (UTC)