Proposed automated edit of phone numbers in the USA

Communities United States
,
1

Motivation

There are many phone numbers in OSM which are not in the agreed format, which includes a country code and excludes most punctuation. This makes it difficult to find actual issues with phone numbers, such as where a number has been transcribed incorrectly in a way that makes it invalid.

I have created the Phone Report website which suggests fixes to phone numbers and identifies invalid phone numbers. This has been in use over recent weeks to fix many phone numbers. Some of those changes are very simple and similar to each other and could be made automatically.

Making automatic changes in simple cases saves mappers’ time and allows them to spend time on identifying and fixing actually invalid phone numbers.

Proposal

I propose to run an ongoing automated edit on objects with phone, contactːphone, mobile, contactːmobile or phoneːmobile in the USA and territories to reformat phone numbers which have extra punctuation or are missing the country code to the format +1-555-555-5555

Edits

Edits will only be made if all of the following applyː

  • The value in the phone tag consists of only digits, spaces, parentheses, dashes, hyphens, periods or invisible formatting marks such as non-breaking spaces, zero-width spaces

  • The value can be parsed using libphonenumber-js assuming a +1 country code

  • The new number is a valid phone number

  • The new number is a US number with +1 country code

  • The new number is different by more than just the addition or removal of spacing characters (spaces and hyphens), for example a country code was added or punctuation was removed

  • The OSM element does not contain any duplicate phone numbers

  • The new phone number is not classified as a non-mobile phone number in a mobile tag

  • And only if all of the above applies to every phone tag on the object

This is a subset of the suggested fixes on Phone Report, in particular it excludes any tag with multiple numbers, the duplicate and non-mobile number checks, any numbers with extensions or any with letters.

The target formatting of the numbers would be +1-555-555-5555 after discussion with members of the US community.

Number of Objects Affected

As of 2025-11-16, in the United States Of America there wereː

  • 33,749 OSM objects with invalid phone numbers

  • Of these, 31,530 have automatic fixes suggested on the website

  • Of these, 28,656 would be affected by by this edit

Once the first edit has been done, it would be only objects that had been edited in the past day that would be affected, likely fewer than 10 per state per day.

If accepted, I would start with a single changeset for a single state, probably Alabama since it is alphabetically first, and post it here for verification before continuing with the rest of the states.

Grouping of Edits

Edits would be grouped by state, with up to one changeset per state per day.

Examples

Example Edits

n13298223257: phone = 3349231048 to phone = +1-334-923-1048

w1450897471: phone = (256) 870-3424 to phone = +1-256-870-3424

Edits suggested on the website but not made by the bot

n9947820920 has multiple phone numbers with an incorrect separator. To be safe, objects with multiple phone numbers in one tag are not included in this proposal.

  • phoneː +1 800 838 9647 / +1 800 835 4386

  • suggested fixː +1-800-838-9647; +1-800-835-4386

n2581950490 the phone value has extra text, which technically makes the number invalid, but it is still parseable with libphonenumber.

  • phone: +1 605-397-8100 "non emergency calls"

  • suggested fixː +1-605-397-8100

Objects not detected as issues

w971256647: phone = +1 410-390-7029

This is not in the agreed format, but is still valid.

Full List of Edits

See here for the full list of edits that would be made by this proposal, as of 2025-11-16.

Timescale

I will wait at least two weeks, until 2025-11-30, for any comments before commencing this edit. The proposal will also be shared to be posted in weekly OSM.

Wiki Page

Reading this but not from the USA?

Once this is accepted and running, I would be happy to extend it to other regions. Let me know if you think this would be accepted in your country and a further proposal could be made. Meanwhile, check the phone report website and look at the suggested fixes. Make some edits and report any errors with the tool.

14 Likes
2

I support this. Thanks for developing that tool and for bringing this forward.

Small correction, I believe this is meant to be +1-555-555-5555. The same typo is on the linked Wiki page :slight_smile:

3

Thanks for laying out this proposal. It looks thorough and in keeping with the recent formatting discussions.

fax=*/contact:fax=* would follow the same format. Might as well knock that one out at the same time, while fax machines continue to be a thing. Otherwise, a novice mapper might see inconsistent Phone and Fax fields side by side in iD and incorrectly make them consistent with the wrong format.

For completeness’ sake, I’ll note that this technically would lose information about whether the area code is optional. However, this is information OSM hasn’t been intentionally collecting, and it’s unclear to what extent mappers have been using parentheses only out of habit without realizing the meaning. If a data consumer needs to recover this detail, it can maintain its own lookup table of which area codes still allow seven-digit dialing and which require ten-digit dialing.

7 Likes
4

I love this and am so happy you’re going to save us all the headache of clicking through the purely mechanical portion of this.

3 Likes
5

That is what it already is


fax=*/contact:fax=* would follow the same format. Might as well knock that one out at the same time, while fax machines continue to be a thing

Thank you, I will add fax and contact:fax to the tool and see how that goes, then update here

For completeness’ sake, I’ll note that this technically would lose information about whether the area code is optional. However, this is information OSM hasn’t been intentionally collecting, and it’s unclear to what extent mappers have been using parentheses only out of habit without realizing the meaning. If a data consumer needs to recover this detail, it can maintain its own lookup table of which area codes still allow seven-digit dialing and which require ten-digit dialing.

I see, this did not come up in the previous thread and so it seemed that others were happy with parentheses being removed from phone numbers in OSM. It has also been on the wiki in the USA section since at least that thread that parentheses should not be included. But as you say, the original intention may be unclear and lookup tables can be used.

6

It was meant to be an explanation of real-world usage, as to why novice mappers might gravitate toward the parentheses. But the convention in OSM has always omitted parentheses and I’m not advocating that you introduce them as part of this bulk edit process.

1 Like
7

It could also be run on Canada 
. I am sure there are many of the same types of errors, and Canada uses the same +1-xxx-xxx-xxxx format.

1 Like
8

I was wondering about how editors handle phone number validation/auto-conversion, and there is an iD ticket from 2016 that came down against conversion. Automatically convert phone numbers · Issue #3495 · openstreetmap/iD · GitHub

So new data will continue to not be standardized. Which probably should be resolved before moving forward with the automated edit.

9

Thank you for the link. My reading of that issue is that some regions may not want the format of the phone tag to be reformatted automatically. That is why this is not a worldwide automated edit but limited to USA, and feedback from US community is being sought.

Additionally, since new data will not be standardised, this will be a recurring automated edit.

10

Until this moment I had no idea that parentheses could have had any meaning other than delimiters.

While I missed the 4 digit dialing era and grew up in the 7-digit era, I never noticed any consistency in how phone numbers might be represented in text in the transition to 10-digit dialing. If there was ever any communication that one shouldn’t use parentheses when a region requires 10-digit dialing I totally missed it.

In my mind any use of parentheses to indicate optionality of the area code is only because they were all optional historically for local calls, not any attempt to encode any present 7/10-digit status.

8 Likes
11

Overall I think this is a great and helpful effort.:+1:

However, I’m a bit confused by that bullet point. As far as I know, due to the “number portability” laws, there’s really no longer a fixed distinction between a mobile and non-mobile number. Any number can be ported to and from cell service.

3 Likes
12

That point doesn’t apply much in the USA/NANP since standard numbers are portable, as you say, unlike some other regions which have specific sections of the numbering plan for mobile numbers.

The only time this comes up in the US is where a toll free number has been mapped in mobile or contact:mobile. As far as I am aware, that is probably an error, and so is flagged by the validator as being “not a cell phone number” and a suggestion is made to move it to phone or contact:phone.

13

How are extensions handled?

1 Like
14

They would not be affected by the bot edit since such the phone tag would contain other characters, e.g. +1-555-555-5555 x123 or +1-555-555-5555 ext. 123.

Ref:

The value in the phone tag consists of only digits, spaces, parentheses, dashes, hyphens, periods or invisible formatting marks such as non-breaking spaces, zero-width spaces

If there is anything else, like letters, then the object is not considered for automatic editing.

The website considers either of those formats above as valid and suggests fixing anything else, like +1-555-555-5555 extension 123 to +1-555-555-5555 x123

1 Like
15

You’re definitely right that the parentheses are mostly a leftover habit, regardless of what it means officially. The distinction between 7- and 10-digit dialing is fast becoming irrelevant in the era of mobile phones and number portability. This gives me confidence that we can standardize on the 10-digit format and make data consumers reformat optional area codes if they really want.

Even so, in less populous parts of the country that still officially have 7-digit dialing, shop signs still routinely show the area code in parentheses or omit it entirely, whereas in more urban parts of the country, such usage is generally limited to ancient signs. These same rural areas are probably more likely to have shops that still use landlines. I suspect that mappers in these areas will be more likely to enter “invalid” phone numbers just based on what they see.

2 Likes
16

Why not use the standard E.164 format? It’s basically what you already have, minus the dashes.

17

We are. E.164 is what gives us the +1 country code. You’re probably thinking of E.123, which optionally and very reluctantly lets North America continue to use hyphens.

3 Likes
18

As I read E.164 - Wikipedia , E.164 doesn’t allow anything other than the digits, and it’s E.123 - Wikipedia that introduces ‘+’; spaces for grouping in international notation; and some other character (e.g., ‘-’) in national notations.

2 Likes
19

Not quite: 1-555-555-5555 vs +1-555-555-5555

1 Like
20

Apologies, I misread your comment. I have fixed both of those.