Talk:Key:phone

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Key:phone here:

Accepted?

What's the status of this key? I don't see it in http://wiki.openstreetmap.org/wiki/Map_features --Jkp 10:46, 17 January 2009 (UTC)

Yes it's not really clear, particularly given that there seems to be a proposal page Proposed features/Phone which was apparently rejected. -- Harry Wood 09:42, 4 August 2009 (UTC)
In my opinion, the key is accepted by the community, as it is currently used more than 25,000 times, although it was rejected in the vote. --Telegnom 07:24, 12 February 2010 (UTC)
If one reads the comments the voters gave, only two out of thirteen were against storing phone numbers altogether, other disapproving voters just wanted to use a different tag.Alv 08:08, 12 February 2010 (UTC)
OK I've written a paragraph describing the status "widely used and accepted by many mappers, however the original proposal, Proposed features/Phone, did not pass the vote" -- Harry Wood 15:22, 26 October 2010 (BST)

Key:phone#Icons

Could icons with phone numbers maybe be rendered on the fly, using for example a site like OpenStreetBrowser? Just an idea. Logictheo 18:22, 30 June 2009 (UTC)

Alternatives

Usage found on OSMdoc March 2010: The zero-value tags were once also used:

phone: 47826
telephone: 1286
telephone_number: 24
phone_number: 15
addr:phonenumber: 3
addr:phone: 891
contact:phone: 3305

udated. --Dirk86 10:10, 15 August 2010 (BST)

In the latest planet dump (2010-02-10) the key phone is found 25331 times

More than one phone number and a distinction

More than one phone number and a distinction: For public service organisations in Greece. One building has many phone numbers. The director/manager has a phone number. The secretariat also. I see no other way than to use note:pstn-phone-number with value where that number is connected to. logictheo 06:10, 12 February 2010 (UTC)

Surely they have a number that one should call when they don't already know the person handling their "case". Alv 08:21, 12 February 2010 (UTC)

What do you think about to seperate kind of phone. It could be that

or something like that is useful.--Dirk86 01:02, 15 March 2010 (UTC)

Many people think that the nice simple phone=* should become contact:phone=*. Now you're taking that further and adding more colons. We're not developing some kind of programming language. For the sake of beginner mappers (most mappers!) you are adding too many colon characters for something which could be very simple -- Harry Wood 18:40, 12 October 2010 (BST)
4 years later and the question still stands: what's the best way to add multiple phone numbers? --Wizrares (talk) 22:50, 15 March 2014 (UTC)
6 years later ... same old question--Plamen (talk) 20:06, 25 February 2016 (UTC)
I second this question; it doesn't happen often, but it does happen that a business has multiple telephone numbers. To name an example, the German logistics company LogoiX GmbH has a German as well as an Austrian phone number for customers to call. -- MrManny (talk) 12:10, 16 October 2014 (UTC)
It's unusual enough that people didn't reach a consensus, but it seems that today there are around 4444 phone=* tags with a semicolon (according to taginfo), so I think it would be safe to use it. --Jgpacker (talk) 12:22, 16 October 2014 (UTC)

Plain old multiple phone numbers

The place has 555-1212, and 555-1313. They are sitting next to each other on the desk, and are both on their advertisements, name cards etc. I.e., if you call one and it's busy you call the other, just like in the old days. Do mention how to enter into OSM, phone and phone1? Jidanni (talk) 02:36, 11 July 2019 (UTC)

You can use a semicolon, e.g. phone=+61 3 9999 3257;+61 3 9999 3258 —M!dgard [ talk ] 08:10, 11 July 2019 (UTC)
OK, they also have a mobile number, in case the bellhop is away from the desk. I suppose I should use phone:mobile=... for that. Jidanni (talk) 03:22, 29 February 2020 (UTC)

Reasons why we should not map phone numbers at all

  • A phone number is not "on the ground", and therefor not an object to store in a map.
  • There is no quality check for phone numbers - They will be old and wrong soon.
  • At the State of the map 2010 in Girona the speaker Katleen Janssen ("OSM and the law") recommends NOT to have phone numbers in the database for personal data privacy problems reason

User:Lulu-Ann - 11:10, 24 February 2010

Are websites, email addresses and webcams "on the ground"? They may also change and become obsolete some time. I consider phone numbers useful for digital maps. Imagine you are on a tour and searching for a place to stay for the night in a given area, then you might want to contact a hotel or something similar before you arrive there to ask for a free room. --Scai 13:14, 12 October 2010 (BST)
But if you are using a wrong email address or wrong website address, nobody is bothered. If you are using a wrong phone number, you might wake up old people who do not even own a computer and have no means to defend against this. --Lulu-Ann 13:43, 12 October 2010 (BST)
So you just don't call phone numbers at all because they might be outdated and you could call somebody who is old and has no computer? :) I think this is a more general problem which has nothing to do with OSM in particular. You might also have other outdated sources of information, for example a booklet of a hotel or restaurant with an old telephone number. I can see the problem you are talking about, but I don't really consider it as a big disadvantage here. --Scai 20:53, 12 October 2010 (BST)
Sure, you would only be the calling person, not the victim of phone terror. There is no quality assurance for telephone numbers in OSM. Nobody can check them. --Lulu-Ann 08:36, 13 October 2010 (BST)
I guess most phone numbers can be checked using the POI's website, if there is any. But you are right, automatic edits could easily be used for things like phone terror. --Scai 20:44, 13 October 2010 (BST)
You are right, phone numbers can be collected from websites, so let's map websites, not phone numbers. --Lulu-Ann 12:07, 14 October 2010 (BST)
Not sure if I understand this phone terror point. Are you saying somebody could set lots of POIs to have one person's phone number, thereby maliciously causing them to receive lots of unwanted phone calls? That's a quite a reaching speculation. At this stage at least, it wouldn't be a very effective way of doing that kind of mischief, as I don't believe many people are using the phone numbers from POIs. It's one of those problems we can address if and when it actually crops up, rather than speculating too much in advance. I imagine we could quite effectively mitigate by checking for the same phone number appearing on more than one POI (as a bug type perhaps) If you were to ask me to speculate on this kind of thing, I'd say we're much more likely to some time soon have a "map spam" problem in the Key:website tag, but again there are ways we can seek to tackle that ...if and when. -- Harry Wood 18:39, 14 October 2010 (BST)
No, you did not the terror point. Terror is what a single phone number owner suffers, if his or her number is in OSM accidently because of a single mistake. Of which we will have thousands, because there is no quality check on phone numbers in OSM. Let's face it, if an OSM user is out on vacation with his bike and GPS phone, an tries to call a hotel from an OSM number and fails, calling an old lady in the late evening instead... Will his thought be to tell her about OSM and the mistake? He will say "Sorry, wrong number". The old lady will never get the chance to get her number out of OSM, because she will not get the information where her number is stored. And even if she does, what effort would it take to find out how to remove it, consider she does not have a computer, internet access and internet user knowledge.
And we have to face the fact that we have more and more OSM users who are not mappers but just users, and won't correct phone numbers! --Lulu-Ann 11:13, 15 October 2010 (BST)
Ah ok. Not really "Terror" then. Just inadvertent phone number errors leading "wrong number" phone calls.
It's a problem with accuracy of our data. A new problem with accuracy of data, which we could avoid by not mapping phone numbers. This is true. Examples of other problems with accuracy of our data: people could get lost, because we're missing some data. Worse! a hiker might fall off a cliff because we had a cliff missing from our map. Worse still! Someone might crash an oil tanker because we had the coastline mapped badly. Like any of these problems we can't guarantee good data. We have disclaimers. We also do what we can to improve accuracy and let people report bugs. These are all theoretical examples. You can let your imagination run wild.
I do take the point though, that it's quite easy for a mapper to type in a phone number wrongly, and fairly difficult for anyone to notice that error (basically we wouldn't notice until someone made a "wrong number" call and then pro-actively reporting a bug somehow) Me might achieve accuracy of >99% (1 in 100 phone numbers is typed wrongly) but probably not on a par with a phone book (probably >99.9%) and maybe end users would mistakenly expect that kind of accuracy.
-- Harry Wood 12:54, 15 October 2010 (BST)
Are you kidding? There have been many cases of people receiving phone calls in stead of a restaurant because the flyers for that restaurant had the wrong number! In some cases even the phone books made such mistakes, that were only fixed in the next edition (which is usually yearly). I myself have been receiving e-mail sent to an Indian man for two years because he apparently keeps writing his address wrong.
Phone numbers that are publicly available and advertised by businesses and similar should well be mapped in my opinion. The possible mistakes are not a problem of OSM itself, and should be addressed the old way. --SimoneSVC (talk) 08:26, 22 July 2013 (UTC)
Can you tell me how any grandmom can fight against having her phone number in OSM in error "the old way"? She won't even get to know where the wrong number comes from. --Lulu-Ann (talk) 15:02, 24 September 2013 (UTC)
She'll tell the caller he has wrong number, and that people keep calling her to order pizza, and ask the caller where did he get the wrong number, and if he can contact the people responsible to fix it. So the nice OSM user who called her would say "sure" and would open an OSM Note, or even fix/delete phone number of POI in question himself, and old lady would live happily forever after. --mnalis (talk) 22:53, 8 June 2014 (UTC)
Most businesses never change their phone number, they would lose customers if they did. There are several possibilities for quality check, including reverse lookup in online phone books. There are maps showing local businesses, including phone numbers. I consider it useful when traveling with an offline navigation device. For privacy reasons you should not tag names of private home owners and their phone numbers, but I am sure businesses will thank you for that. --emka 08:45, 14 October 2010 (BST)
Yes, businesses do not often change their phone number, but some quit, and some numbers will be with typos from the start. There are possibilities for quality check, but they are not used. We are mappers, not phone number checkers. Copying or miscorrecting phone numbers from unsure sources is not only stupid copying of wrong facts, but also copyright violation, at least in some cases. How do you make sure you only add typos that direct to business phone numbers? --Lulu-Ann 12:07, 14 October 2010 (BST)
I kind of agree with this point. Adding lots of phone numbers in, and then maintaining them (trying to fix typos etc) is rather a drain on our mapping energy, and not really very core to the aims of OpenStreetMap. It seems unlikely that we'll ever have a database of phone numbers which is anywhere near as complete or reliable as ...a phone book.
Balance that against the consideration the data has obvious potential use cases: "You're using an OSM powered mobile app to find the nearest pizza take-away, and oh look we have the phone number too. let's order pizza!" Compared with some of the other tagging we do, phone numbers are pretty useful!
This is sort of a moot point anyway, because people will map phone numbers. I guess it's just a question of whether we encourage people to do so. Like anything I'd encourage mappers to think a bit about the data they're putting in. How much effort are you spending which could be better spent elsewhere? Personally I stick phone numbers of shops into the database if I happen to have captured that from their shop sign in my photo mapping. I don't go searching for phone numbers off websites.
-- Harry Wood 18:39, 14 October 2010 (BST)
The solution is easy: There are open yellow pages, that take care of phone numbers. We could link to them without losing comfort for the user, and the open yellow pages should have the means to keep numbers correct. Unfortunately the service is not worldwide, as it seems. So linking to the business website should help to find the non reduntant, up to date phone number ! --Lulu-Ann 11:13, 15 October 2010 (BST)
A few days ago, together with a friend of mine we decided to order from a local Pizzeria. Sadly we had no flyer and they have no website!
Also there was no POI in OSM, so right now I have their flyer in front of me. There's contact information as well as the opening_hours. I just created the POI and added all the data from their flyer. If it happens again that someone wants to call for pizza he may find the data in OSM.
To add contact-data to an POI you have to digg into the wiki and find out how. Once you have done that you won't upload the POI until you've double-rechecked it. I totally agree with Harry Wood; We don't know the potential of our mapping yet; When there's no data, no developer would try to make a mobile App for it^^ and without contact-data added to the POI it's like "Oh cool, there's a pizzeria o.x" and nobody will see the advantage in OSM. --DerKuchen 10:50, 18 October 2010 (BST)
If a pizza service has no website, they deserve to fail. There is no reason why OSM should help them by storing their essential data in the OSM database instead they create a website for themselves. THIS IS NOT OUR JOB --Lulu-Ann 15:36, 18 October 2010 (BST)
Of course it is not our job, but not every little pizza service has to have its own website. Most of them will be known to the local people, and other people can at least use OSM to find (and maybe contact) them. You can't deny that there are advantages with storing such contact information in OSM, but there are also the mentioned disadvantages, of course. --Scai 16:22, 18 October 2010 (BST)
...And in my opinion the advantages clearly outrun the disadvantages! Besides What is our Job? is some kind of philosophical question... --User:DerKuchen
I feel phone number, if in osm at all, should be sourced and matched from an updated source (e.g. the phone directory), not entered by hand. If they are entered by hand that should be a temporary "override" or "correction" record which eventually will be challenged or validated against the primary source (e.g. phone company records). Brycenesbitt 16:53, 31 October 2010 (UTC)
Well it would be good to "challenge or validate against a primary source", but phone books and phone number databases are mostly not released as open data. So it's the same situation as other map data. If we can get our hands on public domain phone number databases, e.g. in a particular area, then we have an interesting question about whether to import (given that it's not clear we want to be holding this data anyway), and also how to import updates, and how to take account of modifications which may be a correction to the "official" dataset (because while a database may have a better accuracy rate, it's unlikely to be perfect and so post-import edits may well be corrections) Actually these are all familiar dilemmas seen already for other types of data. -- Harry Wood 19:24, 13 June 2011 (BST)
We should not copy the data, we sould *link* to the free source. --Lulu-Ann 15:12, 2 August 2011 (BST)
This only works with an open phone database. Links to websites will probably break faster than phone numbers. --Scai 15:47, 26 April 2012 (BST)
+1000 for Lulu-Ann arguments. OSM is a geodatabase, not an open yellow page project. --Pieren 13:27, 26 April 2012 (BST)
Hi guys, I came accross this page by looking for a way to identify phone numbers in OSM data. I am planning to switch my mobile app to using OSM data in the next update, but the lack of phone numbers is a major concern for me. Users will not be able to contact the business, especially if they are off-line and have no means of opening the business' website. Given the chance for having wrong numbers (say 1 out of 10), when out on the road with no Internet access, I would much rather have a 9 out of 10 chance of being able to reach the business than not have any chance at all (i.e. when there is no phone number). Currently I am debating if I should hold my transition to OSM until I can implement a secondary provider to use for cross referencing OSM points of interest with phone numbers and pictures. Just my 2 cents. --Livecarmap 21:36, 9 June 2012 (BST)
I fully agree with you. --Scai 21:26, 9 June 2012 (BST)
I also agree - and this wiki talk page really doesn't matter. People will map the phone numbers, or they won't. The dozen vocal editors on the wiki talk page won't even be seen by the greatest majority of the hundreds of thousands of editors, much less be able to persuade them not to do what they think is useful. So I'd say, just go ahead and use the phone data, and then let your users decide if it's useful to them or not. --mnalis 07:07, 18 July 2012 (BST)

format inconsistency with the key “contact:phone”

For contact:phone=*, this format is suggested, refering to the ITU-T recommendation E.123 and DIN 5008: 

+<country_code> <national_destination_code> <subscriber_number>-<direct_inward_dialing>

On the phone=* wiki page, refering to the same standards, following format is suggested: 

+<country_code> <national_destination_code> <subscriber_number>

We should make both phone and contact:phone consistent, shoudln’t we? --Wuzzy 18:19, 12 December 2012 (UTC)

There's no inconsistency: when dialing, you cannot really distinguist the subscriber number from the last part for the direct inward dialing, because you must always compose both... In addition, there's no standard at all allowing such distinction by length (some subscribers will just get a large block of successive numbers with many direct inward dialing, and even in this case, when calling inward only, you may still have to compose the subscriber prefix in many places (using short numbering is only possible if the local site uses a trunk selection code (e.g. 0 or 1) for calling outward, but this would also require that inward numbers cannot start by this trunk selection code (if these "direct inward" numbers must be called inward, you'll still have to compose the trun selection code before dialing the full subscriber number and the "direct inward" number).
In fact in E.123, separators are never significant, you never dial them: these separators are only existing for mnemonic reasons (you could even drop the spaces between the country code and the national region code, or between this code and the subscriber number)
Many countries have also abandoned completely the national region code and for all calls in these countries, you must dial all digits except the country code, including for local calls. The region codes no longer have any geographic significance (numbers can even be "ported" to other regions even if they remain allocated region by region for new subscribers): the criteria of distance has been abandonned (replaced by distinction of operators and type of network or service: mobile numbers are independant of the region where subscribers are located and no one can know where the destination will be, and there's no distinction in terms of fees payed by the caller; value-added services, or toll-free numbers are also independant of the region of the caller or the destination, they don't fit in this deprecated model.)
In summary, the only useful format is
+<country_code> <national_destination_code+subscriber_number+direct_inward_dialing>
and you can add any separator you want in the second part (spaces, hyphens and dots are common), even if there are some preferences in some countries on the format (but even in the same country, there may be multiple prefered format such as "+33 1 23 45 67 89" in France for geographic numbers or mobile numbers, grouping digits by pairs, but "0 800 123 456" for toll-free numbers grouping digits by triplets (note: there's no country prefix as this number cannot be called from other countries than France!), or "+33 823 456 789" for special numbers that can still be called from foreing countries). For mnemonic reasons, you'll also commonly find formats like "+33 1 45 24 7000" (it is also a geographic non-mobile number but the last two pairs are joined)...
Numbers that don't follow this simpler scheme (because they can only be called from the same country, or only from a specific operator or network) simply don't start with "+" and a country code (this is the case of most "short numbers" available notably on mobile phones, or for emergency numbers such as "112" in every country of Europe, that you MUST dial directly without any prefix, but possibly with a local-specific trunk selection code if you are in a special location like an hotel and don't use your mobile phone).
So don't attempt to parse phone number outside the country code according to its format or separators, it is now complete non-sense if you don't know how the numbering plan is effectively structured and you don't know the many exceptions that have occured now after the liberalization of the telephony market with many operators or services. — Verdy_p (talk) 23:02, 28 May 2015 (UTC)

Multiple numbers: Toll-free

There needs to be a more concise reference on how to add multiple numbers with most commonly used examples such as toll-free numbers. For example for countries in North America many businesses will have a local number and toll-free number NA toll-free numbering system which is good within and between countries which use this system. However it is still not clear the best practice to write this in the tags since toll-free numbers are not confined to one country. It should also be clear to whoever is using the number that it is toll-free (or maybe the client software should be handling that by cross checking with the list of toll-free numbers and telling the user if it's toll-free or not?). Maybe there should be a phone:tollfree=* tag which would imply it's good only from within the country the business in? It is also not clear if there should be one phone tag per number or multiple phone numbers per tag separated by say a semicolon. Currently I've been putting both numbers in the same phone tag separated by a semicolon similar to opening-hours eg "phone=1-123-456-7890;toll-free 1-800-123-4567". Obviously this is not ideal since it is more prone to formatting inconstancies and harder to parse but at least it will be very clear to anyone reading it.

tl;dr: The casual editor should be able to come to this page and be able to quickly understand how to properly add telephone numbers without reading a whole page and still coming out confused. --DFyson (talk) 18:42, 12 February 2016 (UTC)

I've been adding a bunch of phone numbers in the US. I put the main local phone number in phone=* and other numbers in the following:
  • phone:tollfree=*: A toll-free phone number that most likely dials the same as the phone number in the phone tag.
  • phone:mobile=*: A mobile phone number.
  • phone:alternate=*: For businesses that publish two phone numbers for other reasons.
When only one phone number is published then I just use phone=* even if that number is a toll-free or mobile number. This way the value of the phone=* tag is directly dial-able by various consumers of OSM data.
For all phone numbers, I use NANP format: +1-202-555-1234 (note that the +1 is the country calling code for North America and the 3 groups of customarily separated numbers are separated by dashes).
Another common reason for another phone number is a fax machine number which goes into fax=* (or rarely fax:tollfree=*).
--Dobratzp (talk) 21:42, 28 August 2017 (UTC)

Brackets

In Ukraine, for domestic phone numbers, area codes (including the trunk prefix) are usually separated with brackets, e.g.: "(044) 123-45-67".
For OSM, in international format, it should become phone=+380 44 123 45 67; anyway, I've seen phone numbers formatted like "+380 (44) 123 45 67" in some nodes.
Is it really allowed to use brackets in phone numbers on OSM? --Bbbz (talk) 21:41, 30 November 2017 (UTC)

No, it does not conform to the international format. --Kristjan (talk) 09:07, 13 November 2022 (UTC)

Extension numbers

Is there a good way to tag extension numbers? Because I'm not seeing one, but it would be helpful if there was. --Adamant1 (talk) 07:59, 15 June 2020 (UTC)

What is the reason to write down extension numbers? The days of calling several extension numbers until one picked up are hopefully over, aren't they? User 5359 (talk) 15:24, 15 June 2020 (UTC)
I do a lot of mapping of businesses and there instance where departments are in different buildings but share the same phone number with an extension number. Yesterday there was a motorcycle shop, bicycle shop, motorcycle repair shop, and office for the same company that all had the same number with extension numbers for each but the buildings where all a few blocks away from each other. I don't think it would be correct to just use the main office number for all the places in cases like that without including the extension number. Adamant1 (talk) 15:33, 15 June 2020 (UTC)
I don't think that OSM can map the entire (phone) structure of a company. These phone numbers are always the most important phone number of a company: Either the operator, which can transfer you or in a restaurant the reservation (and not the kitchen). User 5359 (talk) 15:38, 15 June 2020 (UTC)
I mostly agree with that. Except we already add separate parts of business as different nodes when they do different things. Like with drug stores that have pharmacies or gas stations and convenience stores. Which more the kind of thing I was asking about. The fact that they have the same number is semi-irrelevant to the practice of doing that and If I'm already mapping them as different points due to the guideline about it then it's pretty inconsequential to add the extension number. I'm not saying we should do something like add contact details for the front desk, the bosses main line, his secretary's phone, and the janitors pager number while we are at it. That's more what I would consider mapping the corporate structure then I would my use case. --Adamant1 (talk) 05:02, 20 June 2020 (UTC)
I may not have fully understood your request. If you have separate points, then you can of course add the key phone at any point. These can always be the same number or different ones. But a marking that this is an extension (or in other words that these numbers belong to a business) is not intended in my opinion User 5359 (talk) 05:14, 20 June 2020 (UTC)
Phone extensions would be very useful to add. I recently came across an example where a marina is run by the City of Kingston in Ontario. The number listed on the website is the generic phone number for the City of Kingston but with an extension for the marina. Without knowing the extension, one would need to contact the operator to get through to the marina. Since there's no documentation to go by, I just used the common notation by adding the extension to the end of the phone number eg "+1-123-456-7890 x1234". DFyson (talk) 16:09, 20 August 2020 (UTC)
The obvious way of using "+1-123-456-7890 x1234" is raised by Osmose as an "Phone number does not match the expected format" level 2 warning. --Fleezing (talk) 20:58, 2 March 2023 (UTC)
There may be, surprisingly on key:contact, though was half-correct. See Talk:Key:contact#Internal_phone_extension_number in detail. ---- Kovposch (talk) 21:02, 23 April 2021 (UTC)
I've copied the relevant part from the RFC for reference. Bkil (talk) 19:01, 16 November 2023 (UTC)

More than one phone number

What is the recommendation if there is more than one phone number?

  • phone=+00 000 000 000; +11 111 111 111
  • or phone=+00 000 000 000 + phone:2=+11 111 111 111
  • or other? maro21 20:45, 10 June 2021 (UTC)
Maybe subotimal but in such cases I tag only one phone number Mateusz Konieczny (talk) 17:56, 11 June 2021 (UTC)
phone=number;number per last bullet point of § Parsing phone numbers and per Semi-colon_value_separator --Pippo6 (talk) 07:57, 27 June 2021 (UTC)

Does the template description need to use a literal plus sign?

There is a dispute over whether the template description has to include a literal plus sign, or whether it would be acceptable to use longer phrasing to avoid the use of those punctuation characters, to ease inclusion of the description in programs that don't take appropriate care to escape punctuation. It's agreed that the main text should include the literal plus, the question is just whether the template description should. Rather than continue reverting, I'm bringing this up here. JesseFW (talk) 23:08, 20 June 2023 (UTC)

In that case I would actually say why not? I mean, simply in general, or specifically for example, either to provide tag combinations or numbers. Are there really such big technical hurdles that have to be overcome? I don't know anything about "escape punctuation". Does this have anything to do with query string encoding? --Chris2map (talk) 15:57, 21 June 2023 (UTC)
The description "in +<country code> <area code> <local number> format" is certainly more clear in my opinion than "in standard international format". (Which format? There are two standard international formats mentioned in the article) When mapping, I noticed that many people omit the country code. I don't insist that the description must sound exactly as it is now, however, how to include in a short description the information that a country code is necessary. I took back your description because your argument was "because it makes taginfo cry" and because I think the previous description was clearer. However, that doesn't mean that we can't come up with a better one. Maybe it's the "<>" characters that are difficult to parse by taginfo, not the "+"? maro21 20:44, 21 June 2023 (UTC)

One suggestion for a new description: A telephone number associated with the object. Use +CC XXX XXX XXX format, where CC is a country code. maro21 20:56, 21 June 2023 (UTC)

I like that, let's switch to it, see how taginfo responds, and go from there. Your point about there being multiple "standard international format"s mentioned in the article is very good, and I appreciate the discussion. JesseFW (talk) 21:44, 21 June 2023 (UTC)

+123456789 "Section" - to tag phone contacts for specific requests

There are many undocumented subkeys in use to tag phone numbers for different sections of a POI, e.g. phone:workshop=+1234567891 and phone:office=+1234567892.
These tags are not standardised and hard to parse properly. While it's not common consensus that so much detail should be mapped at all, there seem to be many mappers you want to have this possibility.

Wouldn't it make sense to allow some free text in the value of the main key?
E.g. phone=+1234567890 "office";+1234567891 "workshop";+1234567892 "appointments"
These additions are simple to filter out for any software (simply strip all non-numeric characters works in almost every case, at most leaving an extra digit at the end that doesn't hurt). They can be easily displayed to the user who can select between different options from a list and allow for better descriptions than the limited options in the key. A similar syntax is also used in opening_hours=* and the related conditional syntax. --Mueschel (talk) 13:07, 26 December 2023 (UTC)

The mixing of different content should not be encouraged. opening_hours=* is an exception requiring rules to be evaluated in order in a specific format. Phone numbers don't need to be.
I oppose phone:*=* and opening_hours:*=* for a different reason. Attributes should be suffixed. There is already workshop=* and reservation=* . They can have workshop:phone=+1234567891 + reservation:phone=+1234567892 . (on a side note, I prefer reservation:url=* over reservation:website=* and absolutely not website:booking=* , to follow opening_hours:url=* ) This follows operator:phone=* .
The difficulty of office=* as a feature can be avoided if it's the main phone number, that's usually the case. phone=* should express the main phone number of interest. However, the presence of emergency:phone=* may also suggest this is acceptable.
A missing gap in opening_hours=* is the lack of specification on multilingual comments. There are a few opening_hours:en=* . At the same time, there are similar numbers of phone:en=* (almost all phone:fr=* appear to be phone:FR=* typo) with different number from phone=* , suggesting they are for English phone calls. They would be in conflict with each other.
If they are assumed to be in order, another possible solution might be to use phone=+1234567890;+1234567891;+1234567892 + phone:description=* / phone:label=* ( User:Nadjita/Routes#New_tag_label=* ) *=office;workshop;appointments .
Philosophically, phone=* should follow the international standards as much as possible. There's already enough variation on spaces vs hyphen, and extension numbers.
—— Kovposch (talk) 19:36, 27 December 2023 (UTC)
Please don't get me wrong: I don't ask to replace phone numbers in cases where they are tagged using a subkey to an otherwise established tag like in reservation:phone=+1234567892. My point is only about free-text subkeys to the phone key such as phone:new_customer=+1234567892 or phone:Hertz=+1234567892. --Mueschel (talk) 13:50, 28 December 2023 (UTC)
Ok that's not what you used as examples. Can you clarify how phone:Hertz=* would be used?
Still, phone:description=* or phone:label=* applies. Or phone:full=* / contact:phone:full=* as in addr:full=* for the instructions?
What about other forms of communication? Different email=* addresses? This won't be limited to phone=* .
In general, the possibility of referencing another tags semicolon multivals hasn't been explored. Or you could use phone:conditional=+1234567892 @ "New customer" ? It has already been used for a few numbers to be called at different times.
—— Kovposch (talk) 18:15, 28 December 2023 (UTC)
phone:Hertz=* comes from this POI: [1] One car rental amenity, but with different phone numbers depending on the company. You're right, the conditional syntax would be sufficient for this, but I wouldn't call it a "condition" if there are several numbers for different sections of the same POI.
And indeed, email=* could make use of exactly the same syntax. --Mueschel (talk) 19:04, 28 December 2023 (UTC)
Are all the rental companies really handled at the same counter? This looks like they should be separate points for separate shops. If it is accurate, it could follow shop=car to be brand=Avis;Budget;Enterprise;Hertz , leading to brand:phone=+19287265737;+19283441822;+19287269923;+19287265160 ?
My intention for the meaning of phone:conditional=* is "if" you are a new customer, you call that number, similar to *:conditional=* @ customers for all customers in other conditions. So "if" you want to call different parts of the PoI, you call that number. It's a user or department condition.
—— Kovposch (talk) 09:00, 29 December 2023 (UTC)
Allowing this will make "actual" conditions you think of messy. Eg phone:conditional=+1234567892 "Workshop" @ (18:00-20:00 "If reserved") ???
—— Kovposch (talk) 09:07, 29 December 2023 (UTC)
Talk:Automated_edits/blackboxlogic/MainePhone#Glosses (though owner:phone=* is more suitable for that case, following operator:website=* and operator:phone=* )
—— Kovposch (talk) 18:38, 28 December 2023 (UTC)
An interesting possibility I noticed in E.123 is forward slash for alternative ending numbers. How would phone=+1234567891/2 be commented in your format?
On a related note, the number of dots can be used to indicate inward dialing. phone=+1234567892... for 3-digit extension number.
—— Kovposch (talk) 20:01, 27 December 2023 (UTC)
No problem here. The software can just read the value, interpret as much as possible as a valid phone number. Treat the remainder as a description until the next semicolon. --Mueschel (talk) 13:50, 28 December 2023 (UTC)

onWay, onRelation

@Bkil: Do you think it's a major change? We can discuss.
So why [phone] should not be used on relations:

  • Because it's a tag used with POIs, and these are not used on relations.
  • I looked through all the relations, and with none [phone] was described as a tag that can be used on that relation. Well, on which - restriction? waterway?
  • In the German version it's already as I set here.

Why [phone] should not be used on ways:

  • Because it is a tag used with POIs, and these are not used on lines. We use linear objects such as roads, rivers or fences on ways, and they don't have phone numbers.
  • In the German version it's already as I set here.

And what are your arguments? maro21 21:59, 20 February 2024 (UTC)

Thanks for elaborating. Note that you can and many do add a POI with a relation and add information to the relation in such a case. This can happen for example with schools composed of multiple buildings (multiple campuses?). Or in general, if someone had added an odd shaped building by extruding parts of it using a multipoligon and then someone wants to add POI tags to this building relation. This oversight made it obvious that you did not discuss it with anyone previously. I'm not 100% sure about unclosed ways. Any opinions on this? Perhaps related to the operator of a rivers or stream for those fishing (or in case of emergency)? What kind of other legitimate use cases exist for linear features where information can be added? Bkil (talk) 10:13, 21 February 2024 (UTC)
"onRelation" doesn't take into account multipolygon relations. They are in "onArea". Are there any other relations where you can use [phone]?
Property tags such as [phone] inherit onNode/onWay/onArea/onRelation from the main tags on which they are used. So if POIs/shops/pharmacies, etc. are not used on ways and relations then neither will the derived tags. maro21 20:08, 22 February 2024 (UTC)
You're right. But then running it through OverPass Turbo did return quite a few hits. Ways: route=ferry, aerialway=*, amenity=bicycle_rental, piste:type=*, bridge=*, communication=line, seamark:type=lock_basin, multipoligons: type=site, type=route, type=building, boundary=religious_administration, boundary=administrative, boundary=local_authority. You can have a look yourself within a small country at a time:
> [timeout:25];(relation[type!=multipolygon][phone]({\{bbox}});way(if:is_closed()==0)[phone]({\{bbox}}););(._;>;);out; Bkil (talk) 20:50, 22 February 2024 (UTC)
These are tagging mistakes. Bridges, pistes, seamarks and other mentioned features don't have phone numbers! maro21 17:05, 25 February 2024 (UTC)
Is there a talk page, mailing list thread or forum topic that you have discussed your actions and opinions before? In all the above cases, they can each have the phone number of the operator provided (be it toll bridge, ski resort or paid lock basin). Bkil (talk) 17:42, 25 February 2024 (UTC)
That should be operator:phone=* , same as operator:website=* , both are listed in Key:operator#Further_details and not uncommon. Unless there's a dedicated number for this facility only. For seamark:type=* , I don't know what else other than seamark:information=* as an equivalent to description=* unstructured.
—— Kovposch (talk) 21:21, 25 February 2024 (UTC)

Do you need any further information from me or from others in the community before proceeding? Should I elaborate some more on the above? -Bkil (talk) 22:06, 28 February 2024 (UTC)

No, I don't need. Do you agree then to add onWay=no and onRelation=no? maro21 21:02, 29 February 2024 (UTC)
I see use in combination with relation type=route and type=site, regarding that onRelation=no seems not to be correct to me for now. --Chris2map (talk) 21:30, 29 February 2024 (UTC)
How many type=route and type=site with [phone] do you see? Do you think that routes have phone numbers or they are mistaggings? maro21 22:25, 29 February 2024 (UTC)
I'd like to refer to my above comment where I have listed those that I found to be (mostly non-mistagging). I urge you to run a very similar Overpass query to verify whether what you want to set to no on random wiki pages does not legitimately occur or not before proceeding with all such edits. If you make us check each and every edit of yours to double check whether you did proceed this way, we will be unwillingly doing the more difficult part of the work instead of you who wants to drive such initiative. So again, you could produce value if you had evaluated each one before blindly editing. If you'd like help with Overpass, we can help you with the syntax. Bkil (talk) 17:43, 1 March 2024 (UTC)
We can assume that my question was not only to Chris, because this is a public discussion and anyone can answer. However, does your answer answers my question above? Was your answer definitely meant to be at this level of indentation? maro21 13:07, 2 March 2024 (UTC)
I find 1116 "route" relations and 616 "site" relations with phone=* and I don't think those are inherently wrong or mistagging. It's certainly a much smaller use case but OK in my opinion. --Chris2map (talk) 08:23, 2 March 2024 (UTC)
I'm missing a good reason why we should limit the applicability. There are certainly major ones and more unusual ones, but all of them would be possible for me. E.g. I wouldn't reduce the use with POIs to just points (nodes). – I edited the data item for sync with the wiki page which is the master and where discussion takes place. --Chris2map (talk) 15:57, 12 March 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:phone&oldid=2678406"