E.164 does not allow for anything other than the leading + and digits, which is what I’m suggesting be used.

E.164 does not allow for anything other than the leading + and digits, which is what I’m suggesting be used.
Not using anything to group the digits doesn’t seem very human-friendly? That’s why E.123 specifies spaces (or hyphens).
100% – the entirety of Vermont is one area code: 802. It’s such a notable thing in the northeast that “the 802” is a slang term for the state.
I imagine it’s just biz owners who simply redirect their toll-free numbers to their cells. I don’t think such numbers are meaningfully different from any other and I think they should be reformatted like everything else.
(Speaking just for US here, and probably Canada.)
Plenty of businesses respond via text though. That’s what makes the difference.
I don’t see how that would prevent auto formatting 8xx toll-free numbers in mobile= tags🤔
Ah, I see what you mean. This thread is specific to the U.S. (and maybe the rest of the North American Numbering Plan Area), but migrating to machine-readable phone numbers would have to be a global discussion. We’re just trying to work within the constraints of E.123 because that’s what the global community more or less agreed on.
When the phone=* and fax=* keys first became popular, smartphones hadn’t become commonplace yet and any use case for tel: URIs seemed theoretical, so the project settled on a human-readable format. At some point, it got codified as adherence to the German DIN 5008 standard, which turned out to be absurd in the NANP. It’s taken years to replace DIN 5008 with the international E.123 standard. That standard has flaws too, as we’re discovering when considering phone extensions. It’s also explicitly incompatible with DIN 5008 for direct inward dialing.
Maybe switching to a machine-readable format could be the next stage in the evolution of these keys. It would require coordination with data consumers already used to displaying the values verbatim to end users. @confusedbuffalo’s validator and proposed bulk edit would lay the groundwork for any such migration, by giving us more confidence that we understand the existing values.
Canada is now included on the website. Once I’ve seen that it’s had a reasonable amount of use (by the progress page) and no issues have come up, I will propose to extend this edit to Canada.
Fax numbers are now included. As of today, there are 35,814 objects with invalid numbers, of which 33,521 have fixes suggested on the website, of which 30,751 would be made by the bot.
I wonder if it still shows an underlying data issue. There are very few of these (maybe 1 or 2 per state, that I’ve seen), so I’d rather just leave them up to human review.
I don’t mind too much about the output format, but since data consumers would already have to assume that spaces or hyphens are being used in the numbers, we may as well make the number human readable to make it easier for mappers. And if a data consumer didn’t want that then it’s trivial to remove all non-digits.
One suggestion to help keep us on track:
I see a lot of discussion about the specific format chosen. I encourage broader discussion about “What is the best format for OSM” to be pushed into another thread. The presented edit should be weighed on whether it presents an improvement to the database (YES imo), if there’s weird corner cases that need addressing (ex: asking about extensions), etc.
My perspective about an argument above
I disagree with the notion cleanup like this shouldn’t happen so long as “bad” formatted values can still enter the database. Bad formatting begets more bad formatting. The cleanup of the DB is continually ongoing for all tags. No tag edit could meet that standard.
Have been going over some of the Canadian numbers manually. The suggested fixes are always good replacements. It appears to function 100% as I would expect it to, well done. I have been using the “edit in josm” to add in a missing few websites, as an added bonus. ![]()
Since my posts may be interpreted that way, I want to clarify: I’m in favor of this automated edit moving forward, independent of fixing, for example, the iD format validation.
Just to be perfectly clear about E.164: that document defines the structure of telephone numbers, not the format. It tells you that a telephone number must be composed of a country code, some sort of intermediate identification code (area code, in North America), and a subscriber number. The overall maximum length of country code + identification code + subscriber number must not exceed 15 digits, and the minimum combined length of identification code and subscriber number must be at least 10 digits. (I.e. with a three-digit identification code, like a North American area code, the subscriber code therefore must be at least seven digits.)
Beyond that E.164 says NOTHING about how to write down a phone number. There is no such thing as a “standard E.164 format” telephone number, because the standard does not pertain to the formatting of telephone numbers. It says nothing about a preference for spaces, or no spaces, or hyphens, or parentheses: nothing. The only thing it says is “In accordance with ITU-T E.123, the symbol ‘+’ is recommended to indicate that an international prefix is required.”
E.123—Notation for national and international telephone numbers, e-mail addresses and Web addresses—has recommendations for formatting. A “national phone number” is the format that is expected to be used to dial within the national phone network, and “international phone number” is the format to be used to dial from outside the national phone network. The standard says that a phone number format should consist of diallable symbols (i.e., the numerals 0 through 9, # and *), procedural symbols, the international prefix symbol (+), and spacing symbols.
Contrary to the idea that E.164 (or E.123) ‘standard’ numbers should consist only of digits and the + sign, E.123 very specifically recommends that numbers be grouped (“Grouping the digits of a telephone number is advisable for reasons of memorizing, oral presentation, and printing”) and they are grouped with spacing symbols. With respect to spacing symbols, the standard reads:
Spacing symbols are symbols which are used solely to separate parts of a telephone number from each other. They cannot be diallable, procedural or information symbols.
9.1 Grouping of digits in a telephone number should be accomplished by means of spaces unless an agreed upon explicit symbol (e.g. hyphen) is necessary for procedural purposes. Only spaces should be used in an international number.
Hyphens are “the agreed upon explicit spacing symbol” in North America. The North American Numbering Plan Administrator (NANPA) and the Canadian Numbering Administrator (https://www.cnac.ca/) both use XXX-XXX-XXXX as the standard telephone number format.
As such, the typical national phone number in North America is “XXX-XXX-XXXX” (per NANP), and international number should be “+1 XXX XXX XXXX” (per E.123).
There’s actually an entire section of E.123 about the use of parentheses:
7.2 Use of parentheses
The symbol ( ) (parentheses) should be used to indicate that the digits within the ( ) are not always dialled.
The ( ) should enclose:
- the trunk prefix and trunk code in a national number
- the trunk code when the trunk prefix is not in universal use within a country.
This is done to remind the user not to dial the enclosed digits for calls within the same numbering area.
The ( ) should not be used in an international number.
Historically it was common to put the area code in parentheses to indicate that it didn’t need to be dialled for local calls within the area. As far as I can tell from a cursory web search everywhere in the US has transitioned to ten-digit-dialling as of a couple years ago. (Canada has, except for the territories [area code 867].) As such the parentheses to distinguish seven vs. ten-digit dialling is moot at this point.
As far as I can tell from a cursory web search everywhere in the US has transitioned to ten-digit-dialling as of a couple years ago.
Until recently, only large metropolitan areas transitioned to ten-digit dialing for local numbers, whereas other areas would only encourage ten-digit dialing for compatibility with other local area codes. Local ten-digit dialing didn’t become mandatory until some months before one of the local area codes got an overlay complex.
A few years ago, 9-9-8 was introduced for the Suicide and Crisis Lifeline, causing a conflict that led to mandatory ten-digit dialing in more area codes that didn’t have overlay complexes, even in some rural states:

Seven-digit dialing persists in some parts of the country. A mapper is much more likely to encounter a brand-new shop sign listing a seven-digit phone number in Cleveland or Bismarck than in Cincinnati or Pierre. This should be neither here nor there for the proposed bulk edit, except to say that we’ll probably keep seeing more tags needing correction from these places over time.
Seven-digit dialing persists in some parts of the country. A mapper is much more likely to encounter a brand-new shop sign listing a seven-digit phone number in Cleveland or Bismarck than in Cincinnati or Pierre.
We still have lots of seven-digit numbers around, especially in the smaller towns. Sioux Falls and Rapid most everything’s ten-digit that I’ve been seeing. Locals will still say their seven-digit number just assuming a 605 area code in the small towns.
I broadly support an edit to regularize. However, I have two concerns.
Background: The normal form is “(212) 555-1212”, and I’ve seen “212 555 1212”. I’m not sure I’ve seen “212-555-1212”. We just don’t put a hyphen between area code and exchange. (I agree that with portability that there is no certain geographic correspondence, but it’s still called an area code!)
In the US, a phone number might be written 1-212-555-1212. However, that initial “1” is not a country code, it’s a long-distance prefix – it just happens to be the same digit.
Serious: The form “+1-212-555-1212” is bizarre and is never used in the US. Anyone here who is not a phone nerd would immediately conclude that it is erroneous. The form “+1 212-555-1212” would be perceived as merely odd but not confusing.. I have never seen anyone use a hyphen between the country code and phone number.
Minor: The International norm is “+1 212 555 1212” and I see no reason to deviate from it. People in the US may find that to look a little Euro, but they aren’t going to be confused.
Bottom line, regularize to “+1 212 555 1212” and lose the hyphens, especially between country code and number.
As above, let’s not turn this into a format discussion at the cost of useful gardening of the database.
However, Minh Nguyễn did an in depth look at formats a couple of years back, indicating, if anything, a lack of any standard. Of those in that list with a leading 1 or +1, most include hyphens in at least most positions.
A mechanical edit to a bad form is not progress. Part of approving a mechanical edit is getting rough consensus about what the form should be.
As I said, there is 1-AAA and +1 AAA and the 1 is the same ASCII digit but it has a totally different meaning in the two forms. So rewriting one to the other is a semantic change and that has to get the representation right.
As your proposal stands to use +1-212-555-1212, I am opposed as I think the result is broken. If you amend to “+1 212-555-1212” then I’m ok and if you amend to “+1 212 555 1212” then I am an enthusisastic supporter.
I’m not sure I’ve seen “212-555-1212”.
I’ve seen it, it’s quite common around here.
I am in full support of this edit, and I even updated my phone numbers in my work email signature to line up with the proposed format.
I have never seen anyone use a hyphen between the country code and phone number.
Even despite mass edits to the contrary, the statistics show that most mappers use a hyphen between the country code[1] and area code when they expect to enter a “globalized” number. We can speculate about the reasons all day. Maybe one factor is the placeholder in iD’s Phone Number field. This has been unchanged since 2016, from a time when the wiki officially recommended DIN 5008, which is incompatible with North American numbers. But even Go Map!! users are going out of their way to input that hyphen despite the iOS numeric keypad making it difficult to do so. And the use of hyphens in these tags is not even exclusive to North America.
Which is what ITU standards consider it to be, or trunk prefix if you like. ↩︎
As above, let’s not turn this into a format discussion at the cost of useful gardening of the database.
![]()
From the opening comment in this thread, your examples of what this edit proposes to change:
phone = 3349231048tophone = +1-334-923-1048
phone = (256) 870-3424tophone = +1-256-870-3424
phone = +1 800 838 9647 / +1 800 835 4386tophone = +1-800-838-9647; +1-800-835-4386
phone = +1 605-397-8100 "non emergency calls"tophone = +1-605-397-8100
You’re proposing to change slashes and other unsupported special characters to e.g. semi-colons, deleting explanatory text remarks contained in quotes, and then otherwise getting rid of NNNNNNNNN and (NNN) NNN-NNNN formatting and making them +1-NNN-NNN-NNNN.
So let’s not kid ourselves: this was always a discussion about formatting, and the vast majority of your proposed automated edits will be format changes. It’s perfectly reasonable and expected that commenters on this will want to discuss the proposed formatting.
That said,
Background: The normal form is “(212) 555-1212”, and I’ve seen “212 555 1212”. I’m not sure I’ve seen “212-555-1212”. We just don’t put a hyphen between area code and exchange.
Maybe you don’t have ten-digit-dialling yet? Here, where that’s been a ‘thing’ for almost 20 years and we have multiple overlapping area codes all of which are ‘local’: NNN-NNN-NNNN is perfectly normal and encountered all the time. And as I commented above, the North American Numbering Plan Administrator—the entity whose purpose is to standardize these sorts of things—says NNN-NNN-NNNN is “the format usually represented”.
Anecdotally you may not write numbers in the NNN-NNN-NNNN format, but across North America it’s a perfectly normal and acceptable way of doing it. “(NNN) NNN-NNNN” is still perfectly valid, but it’s definitely becoming an anachronism where NNN-NNN-NNNN is commonplace.
Serious: The form “+1-212-555-1212” is bizarre and is never used in the US. Anyone here who is not a phone nerd would immediately conclude that it is erroneous.
Of course it’s bizarre: we typically omit the leading ‘+1’ because for the vast majority of telephone system users making local calls and international US-to/from-Canada/Mexico/etc calls within the NANP, it’s totally unnecessary. The only people who’d know what the hell the leading + even means are “phone nerds”.
The form “+1 212-555-1212” would be perceived as merely odd but not confusing.. I have never seen anyone use a hyphen between the country code and phone number.
So…
A hyphen instead of a space is “confusing and erroneous”? C’mon man, don’t be ridiculous. The grouping of numbers into a three-digit area code, three-digit local exchange code, and four-digit subscriber code is what’s important; the spacing character used between those groupings is not that big a deal. It doesn’t take a rocket surgeon to figure out how to dial a phone number with a hyphen in it, and in point of fact it’s a perfectly normal and acceptable way of writing it. If anything I’d argue the opposite: using spaces instead of hyphens is weird and ‘foreign’. Understandable, but weird.
Personally when I enter phone numbers in the map I write them “+1 NNN-NNN-NNNN”. I know it’s a mish-mash of spaces and hyphens: I don’t care, it’s what I’m used to. If someone wants to change the space to a hyphen or the hyphens to spaces I couldn’t care less, anyone who wants to change the formatting: fill yer boots. But either way I’m not changing the way I write phone numbers.