Proposal talk:Add ability to specify ordering-only phone number, sms-only phone numbers and related tags

What orders

It is unclear whether this is for takeaway and deliveries, or an electronic (viz phone QR code, or tablet provided by more sophisticated chains) self-ordering system for dine-in completely (saves labor, and evolved from the Coronavirus pandemic). The latter is obviously inapplicable for these, as a dynamically generated QR code is needed for each table at each table.
takeaway=* , delivery=* , and drive_thru=* are standard. You don't need to invent another prefix. It can happen that different systems are used for takeaway=* and delivery=* separately. For your concern of "over-use" that I don't understand yet, ~600 delivery:partner=* already exists, but without the ability to link to the app directly.
If the need is for the same page for all these methods, you have to consider the *:orders=* below. But that doesn't show what methods are available together.
There are ~100 mobile_ordering=* and mobile_ordering:app=*. That's not generic enough. The latter has redundant meanings between mobile and app. It is ambiguous for dine-in customer self-ordering system.
—— Kovposch (talk) 23:12, 22 May 2024 (UTC)

Thanks for the information. I had not considered the word "takeaway" (U.S. English is "take-out" but OSM is British English). As such, I think it would make sense to change the whole proposal to adding takeaway:ordering:*=*, delivery:ordering:*=*, and drive_thru:ordering:*=* to identify the means-of-contact for each kind of order. To include that last option, there doesn't appear to be a dine_in=yes/no/only equivalent as it is implied by amenity=restaurant, so no way to indicate a self-ordering system in the same way.

--JOlshefsky (talk) 00:50, 23 May 2024 (UTC)

I don't find the *:ordering:*=* infix necessary. takeaway:*=* etc is simpler.
Dine-in can be ignored. It's more complicated.
—— Kovposch (talk) 11:34, 23 May 2024 (UTC)

Comparison of suffixes with other features

For the age-old controversy of contact:*=* vs unsuffixed, there is a problem with conflicting meaning of Key:sms for whether SMS is available. There does exists payment:sms=* , but also not much fewer authentication:short_message=* (although admittedly some variations exist there).
Although there are ~260 website:orders=* for shopping in generally, I personally don't agree with the website:*=* suffixes. There's already opening_hours:url=* to follow. While there may seem to be only some dozens of reservation:url=* , both reservation:website=* and website:menu=* have been added en masse from similar instances in 2023 and 2022, showing the number has been inflated. It has been argued suffixing *:url=* is better. Talk:Order_of_key_parts#reservation:website_<>_website:reservation ( lunch:menu=* is mentioned in Key:opening_hours#Related_tags, and lunch:menu:url=* originates from Proposal:Key:lunch#Some_further_consideration_for_possible_extra_tags_(better_names_welcome) )
The meaning of *:website=* is different in brand:website=* , operator:website=* , heritage:website=* , etc. Those mean the website=* of such entities. opening_hours=* and these are attributes, not something existing on their own. Cf the special example of source:url=* to retrieve the source=* from that url=* .
—— Kovposch (talk) 23:35, 22 May 2024 (UTC)

I'm not exactly sure what you are getting at with this comment ... I am making a big assumption that any *:sms=* would always need a phone number. If it were linked to contact=* or the proposed ordering=* (or the takeaway/delivery:ordering=* variant I discussed above) it seems unambiguous to me. Did you mean that it's *:sms=yes/no?

--JOlshefsky (talk) 00:59, 23 May 2024 (UTC)

sms=* is documented in Tag:amenity=telephone#Tags_to_use_in_combination already, so we need to consider whether contact:sms=* will cause people opposing contact:*=* to use sms=* differently. Otherwise, existing meaning is affected.
I prefer *:url=* over *:website=*
—— Kovposch (talk) 11:45, 23 May 2024 (UTC)

Revamp the proposal per discussion above

The previous discussions were related to using "ordering=*" rather than (the update as of yesterday) adding contact:*=*-like sub-tags to takeaway:*=*, delivery:*=*, and drive-thru:*=* as well as adding ordering:sms=*, and contact:sms=* to indicate the capabilities of each of those phone numbers. JOlshefsky (talk) 20:00, 31 May 2024 (UTC)

Use as suffix

To start with phone and add suffixes is what I would do. Is it necessary to distinguish delivery, shipping, takeaway, drive-thru, etc. for the phone number? Are there cases of different phone numbers? I would look for an entry like phone:*=# so IMHO phone:ordering=# would be a simple solution, like phone:reservation=#, phone:service=#, wouldn't it? This is the simple one. If we wanted to define a more universal catch-all solution we'd have to go for something like contact:*:phone=#, contact:ordering:phone=#. --Chris2map (talk) 13:00, 2 June 2024 (UTC)

I agree that the whole takeaway/etc. delineations are not ideal, and IMO phone:ordering=* would be just as logical: reversing the hierarchical order of what-action (takeaway, delivery, etc.) versus what-method (phone, website, etc.) It seems the tagging expanded "organically" so perhaps originally there was phone=*, but (especially as COVID hit) takeaway orders dominated, and restaurants particularly added special ways to order. Nonetheless, takeaway=*, drive-thru=*, and delivery=* have already been established as a solution.

To respond to your concerns more directly, I believe that phone=* is fine if that suffices, but the other tags are useful for when there are special cases (e.g. takeaway:website=https://YakFood.OrderingProvider.com/ for a regional/local restaurant with a special ordering site.) Thanks for your attention to detail!

JOlshefsky (talk) 14:05, 3 June 2024 (UTC)

Thank you for your response! For me it would be more natural the other way around. I can't fully explain why. If I'm looking for contact information or a phone number, phone:... is the simpler logic for me. And it would also sort all the phone numbers entered for an object one after the other. --Chris2map (talk) 16:14, 4 June 2024 (UTC)

If I want to order, I want to look at what modes they have. Preferably websites, apps, and messaging that I can browser through the menu, leave a record, and not be blocked by other calls or busy staff at lunch peak hours.
Sorting is a software limitation. It's up to how they interpret. They can equally identify all phone numbers, and provide a view grouping them together.
*:phone=* suffix is quite established in emergency:phone=* and operator:phone=* . takeaway=* etc attributes are main standards, that can be extended reliably. *:name=* and *:wikidata=* are used, not name:*=* and wikidata:*=* , if someone wants to look at all names and Wikidata items about an object.
There are still other ideas about different phone numbers, viz Talk:Key:phone#More_than_one_phone_number (suggesting *:conditional=* or Template:Opening hours style syntax), that doesn't favor main phone:*=* suffix. It's not well-developed yet.
phone:*=* has been used for different purposes, eg phone:mnemonic=* , and phone:tollfree=* or Key:phone#Support_for_multiple_countries codes. For the former, there is a likely case when the order number can be remembered by words, then it can be delivery:phone:mnemonic=* .
—— Kovposch (talk) 05:59, 5 June 2024 (UTC)

I see your arguments and they make sense too. I think starting with phone: is even easier, at first glance, but :phone could be better, even in more complex cases. I have to and will be able to get used to it. Logically, if you consider delivery and other features as sub-features, then the multiple phone numbers do not refer directly to the main feature, but each one to a certain sub-feature, such as delivery. --Chris2map (talk) 06:21, 6 June 2024 (UTC)