From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Key:phone here:


What's the status of this key? I don't see it in --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)


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)


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 3258M!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)


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

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)