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

From OpenStreetMap Wiki
Jump to navigation Jump to search

Before voting

What orders

Resolved: Updated proposal.

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

Resolved

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

Resolved

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)
I think I would prefer to put the reason as suffix, like phone:ordering=* , like it is for website:orders=*. I think that which of two different systems seems the better depends on the reasons we are looking for the information. If we want to pay and we want to know which options of payment are accepted it is useful to have them together grouped in payment:*=* . If we already want to make a phone call to the POI it is more useful to have them grouped as phone:*=*, exactly like in the old contact books when we used to write phone numbers with pens. On the contrary if we have already decide that we want something deliver from that POI it is more useful to have all the tags grouped as delivery:*=* . The difference is even evident from what, in the keys, I have chosen to write explicitly and what I have written as an * --AnyFile (talk) 13:02, 1 July 2024 (UTC)

Re: 21 June 2024 comment by Mueschel in initial voting

Resolved: Updated proposal.
"There was a proposal (which I read) to add "ordering:" keys announced in the forums. The voting now is on something completely different. (1) As Flo2154: "drive-thru" is a bad idea. (2) "contact:sms" is already in use with a phone number. yes/no doesn't make sense IMO ("There is a way to send an sms, but we don't tell you how"). (3) The keys 'phone:delivery', 'phone:orders' and 'phone:takeaway' are already used in some dozen places. (4) What happened to "orders"? The proposal ignores the hundreds of orders-related tags, e.g. "website:orders". (5) common ways of sending orders, e.g. Whatsapp are missing. (6) Explicitly defining a limited set of tags, including obscure things like "drive-thru:tty" (was that ever a thing anywhere in the past decades?) seems problematic. A proposal should define the generic use of "delivery", "takeaway" or "orders" namespaces and link to the "contact:" keys for definitions of subkeys."

Addressing each point for discussion: (1): I didn't notice that [drive-thru:*](https://wiki.openstreetmap.org/w/index.php?title=Key:drive_thru&redirect=no) redirected to [drive-*through*:*](https://wiki.openstreetmap.org/wiki/Key:drive_through) which is the correct tag. I'm fixing that and will re-initiate voting after another comment period.

(2): contact:sms=* is a portmanteau of contact=* and the "undocumented" key sms=* which calls for yes/no. According to its taginfo, the current usage is dominated by yes/no with phone numbers appearing <0.5% of the time. I agree that yes/no doesn't make sense but for now I'm not going to fight it.

sms=* has nothing to do with contact options. It's about the technical possibility to send sms from a public phone booth. Obviously there's no number needed there. contact:sms=* is something completely different. --Mueschel (talk) 20:30, 24 June 2024 (UTC)

(3): For instance, both phone:delivery=* and delivery:phone=* are in occasional use, neither are very popular. As noted before, this is just a difference of hierarchical order of what-action (takeaway, delivery, etc.) versus what-method (phone, website, etc.) By precedent, contact:phone=* for instance is in use over 800,000 times versus the undocumented phone:contact=* in use 7 times, so delivery:phone=* would fit that model better.

(4) / "'ordering:' keys announced in the forum": I redid the proposal because delivery=*, takeaway=*, and drive-through=* are already established, so we decided it was not preferential to add a new "ordering" prefix (nor a orders=* key).

The change is fine, but it wasn't obvious from the posts and topic title. --Mueschel (talk) 20:30, 24 June 2024 (UTC)

(5): Your specific example of Whatsapp is already in use as contact:whatsapp=*. I didn't want to overload the proposal, so I stuck with replicating the "contact details" section of contact=*.

(6) tty: Living in a city with a large deaf population, TTY numbers are more prevalent. contact:tty=* is in rare use, and given newer text-based technology, it is probably on the decline. Nonetheless, it's a valuable service for some that warrants inclusion in my opinion. It doesn't seem harmful to include it.

(7) proposal: I'm unclear what you mean by "A proposal should define the generic use of "delivery", "takeaway" or "orders" namespaces and link to the "contact:" keys for definitions of subkeys."

What I mean is that this proposal should not try to define a (limited) set of fixed keys. This brings a lot of problems: later extension to tags that were forgotten, possible inconsistencies between contact tags in different contexts, or the need to redefine what 'sms' means. Instead, if you simply define, e.g. a "delivery:*" namespace and define that subkeys are the same as defined in 'contact:*', then we'll always have a consistent way of tagging. This immediately solves my points 2,5 and 6. --Mueschel (talk) 20:30, 24 June 2024 (UTC)
Thanks. That is a good idea. I'm not sure why I couldn't make sense of your point #7! :) --JOlshefsky (talk) 11:51, 25 June 2024 (UTC)

Re: 21 June 2024 comment by Kovposch in initial voting

Resolved: Updated proposal removes specific sub-tags.
"I would want to discuss *:website=* vs *:url=* further, and whether contact:sms=* meaning and style is good vs other contact:*=* and sms=*"
Looking at the tag info, contact:website is in use over 600,000 times versus [1] in use 90 times, so even though the "universal resource locator" is more accurate, it seems most people just use "website".
I'm troubled by the "yes/no" use of contact:sms=* as well, but in the tag info for sms, "yes/no" dominates over 99%. I can see why this makes sense because there is not really a "SMS number" but a "phone number" which may or may not accept SMS messages.
  1. I'm referring to opening_hours:url=* , not contact:*=* . The prefixed contact:website=* is a competitor to website=* . operator:website=* suffix is the website=* of the operator=* . But a delivery=* option isn't something that has a website=* . It's a link where you find the delivery=* option, what can be ordered, and how to order it. So this seems closer to the meaning of opening_hours:url=* for a link where you can find such info. What website=* would be suitable for is eg delivery:partner:website=* , which can mean the website=* of the delivery:partner=* .
  2. contact:whatsapp=* is still a phone number. The question is whether contact:sms=* should be encouraged instead of extending sms=* , when unprefixed phone=* is still more numerous.

—— Kovposch (talk) 20:00, 24 June 2024 (UTC)
(1) I think Mueschel's suggestion "solves" this. By making the new tags refer to the subkeys of contact=*, the sms issue can be resolved. (2) I take your point about URL versus website, but I think the difference is pretty nuanced. There's also the issue of very frequent overlap of takeout:url/website=* and delivery:url/website=* when URL makes more sense (and unfortunately cluttering/confusing the tagging.)
Again, Mueschel's suggestion moves these issues out of this proposal, to-be-addressed in a separate — and possibly more far-reaching — proposal. --JOlshefsky (talk) 12:02, 25 June 2024 (UTC)

Don't redefine used tag

Resolved: Updated proposal.

See mueschels comment. contact:sms is already in use with phone numbers (even if only 121 according to tagingo). You shouldn't redefine used tags in OSM Wiki! Robybully (talk) 14:30, 30 June 2024 (UTC)

sms=* is "documented"—albeit as an undocumented tag with yes/no values, with taginfo reporting around 2,500 uses. However, you're right that contact:sms=* is used differently, exclusively with phone numbers. I'm going to update the proposal with these changes in a little while.--JOlshefsky (talk) 11:27, 4 July 2024 (UTC)

Does SMS really need to be specified?

Resolved: Updated proposal.

Consdering theres different standards of sending text via SMS and RCS for example. It doesnt make sense to tie the tag to a specific techology standard that could quickly change over time. Mxdanger (talk) 20:02, 3 July 2024 (UTC)

I think that SMS is the generic name used by the generic public, without taking into account any technology specifications. It is the term you can find in the business cards or in the contact section of the website (at least for the very small number of them that still write it) --AnyFile (talk) 10:10, 4 July 2024 (UTC)
It can be called "text" (us) or "text message" , but that's ambiguous with chat apps. I don't know how the industry categorize it and MMS. Cellular messaging??? As oppose to chat apps, and RCS, being Internet messaging. But then RCS is the replacement of SMS.
—— Kovposch (talk) 04:11, 5 July 2024 (UTC)
In general, I agree, but the relatively long-lived and wide-spread standards like this deserve to be called out. I admit that SMS is infrequently used, but as I note in the rationale, I found a restaurant that had an SMS-only ordering phone and had no way to tag that. Ideally, there would be a way to "future-proof" this and tag any technology as it appears. But I hope you agree that it is way outside the scope of this proposal to do such a radical change.--JOlshefsky (talk) 11:39, 4 July 2024 (UTC)
There is a problem in authentication:*=* using *:short_message=* and *:phone_call=* , not consistent with unprefixed and contact=* . But to be fair, technically *:short_message=* may appear to be more agnostic, despite only being the full form of SMS.
—— Kovposch (talk) 04:08, 5 July 2024 (UTC)

Change to proposal to reference contact:*=* sub-tags rather than duplicate them.

Resolved: Proposal reflects these changes.

From the discussion so far, I changed the proposal. I removed duplication of the contact:*=* sub-tags, instead making a reference to them, and I extended the voting date to allow for more comments.--JOlshefsky (talk) 12:07, 4 July 2024 (UTC)

Prefixed services

One of my concerns for OSM in general (not limited to this proposal) is how contact:whatsapp=* etc channels should be suffixed. Considering the logic of delivery:phone=* is phone=* in delivery:*=* , suffixing delivery:whatsapp=* directly doesn't follow how there is no unprefixed whatsapp=* . It can create the same mess that unprefixed apps would have.
Unfortunately, contact=* is already mixed with contact:housenumber=* etc from addr:*=* . On the contrary, there are some operator:addr=* , where contact:full=* would be unclear it is a form of addr:full=* , and operator:addr:*=* has been suggested in Key:operator#Further_details .
—— Kovposch (talk) 03:50, 5 July 2024 (UTC)

Yeah, that's a big one for sure. I think the broader issue is whether tagging refers to the physical location, or to the occupants/business/use at a location ... something I figure must be a long-standing issue in cartography. A mountain lasts for a long time compared to a roadway which lasts a long time compared to a building, etc., so what do you document and how do you differentiate? Even an unprefixed phone=* doesn't really make sense for a physical location, just like an unprefixed whatsapp=*, and our human minds make sense of it most of the time. But the tagging is also used to present the information intelligently and concisely by machine, so a hierarchy makes sense. It seems like the operator:*=* was an attempt to fix that but it never really caught on.
Worse yet, at least for the structure of information, is that any editor can create any tag and fill it with any information. But the same flexibility is one reason OSM is so usable: that an editor can create a tag to fill a new need at editing-time rather, to be (theoretically) corrected later. WhatsApp is a great example since it came to popularity fairly recently.--JOlshefsky (talk) 11:53, 10 July 2024 (UTC)


After voting

Re: 19 July 2024 comment by Woodpeck et al

In reference to Woodpeck, Nadjita, and Mateusz Konieczny's comments, I'll be sure to note that these new tags are only if the general contact method is not for ordering, and that the website ordering site should be unique to the establishment and not a generic delivery service.

Created and edited keys as needed

I changed/created the following tags:

--JOlshefsky (talk) 20:58, 4 August 2024 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Add_ability_to_specify_ordering-only_phone_number,_sms-only_phone_numbers_and_related_tags&oldid=2757732"