Proposed automated edit of phone numbers in the UK

Motivation

There are many phone numbers in OSM which are not in the agreed format, which includes a country code and excludes most punctuation, and such numbers keep being mapped. 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, phoneːmobile, fax , contactːfax or contactːwhatsapp. in the UK to reformat phone numbers which have extra punctuation or are missing the country code remove the punctuation and add a country code.

This automated edit has already been discussed and accepted in the US community and is running there.

Edits

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

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

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

  • The new number is a valid phone number

  • The new number is a UK number with +44 country code

  • The new number is different by more than just the addition or removal of spaces, 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.

Number of Objects Affected

Over the past months I have made many edits manually, so this does not affect many objects, but will save manual effort going forward. As of 2025-12-02, there wereː

  • 387 OSM objects with invalid phone numbers

  • Of these, 89 have automatic fixes suggested on the website

  • Of these, 73 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 day.

Grouping of Edits

Edits would be grouped by the regions shown on the website, such as East Midlands, Greater London, Wales, Scotland etc., with up to one changeset per region per day.

Examples of edits that would and would not be made

Example Edits

n1769294100: phone=020 7256 3240 to phone=+44 20 7256 3240

n697306695: phone=+4401200423267 to phone=+44 1200 423267

Edits suggested on the website but not made by the bot

w156454940 has a number that looks like a landline in a mobile tag, which is suggested to move to the main phone tag. In this case, it is a textphone number which may need other tagging.

  • mobileː +44 3456 000 606

  • suggested fixː phone = +44 345 774 0740; +44 345 600 0606 (appending the number to the existing phone value).

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

  • phoneː +44 115 929 6251 'lower-school';+44 115 900 8624 'sixth form'

  • suggested fixː +44 115 929 6251; +44 115 900 8624

Such cases could be considered valid, or could show that more detailed mapping would be needed.

Objects not detected as issues

w589640152: phone =+441843 229 484

This does not have a space after the country code, so is not in the target 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-12-02.

Timescale

I will wait at least 10 days, until 2025-12-12, 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 UK?

I am happy to extend this edit 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.

7 Likes

I’m happy for this to go ahead.

For completeness, it might be worth including any malformed fax and contact:fax numbers in the edit.

3 Likes

Thank you, I actually already planned to include them, as well as contact:whatsapp, but I had neglected to mention them in the post, I’ve added them now.

2 Likes
404 - page not found

Fine with this, honestly assumed some sort of bot was already doing this (I generally don’t add the international prefixes when out surveying because the plus key isn’t on the keypad :upside_down_face:).

2 Likes

Fixed: phone-report/safe_edits_sample/UK_2025-12-02 at main ¡ confusedbuffalo/phone-report ¡ GitHub

(Discourse seemed to be mangling the link with a space in it before)

1 Like

I found an interesting edge case. Short code numbers such as the pan-European 116 number range often cannot be dialled from abroad by adding an international dialling code. This means that the Samaritans number listed on this page is actually valid, not invalid as suggested: OSM Phone Number Validation Report - West Midlands

Whether is is actually right to tag that number on the object in OSM is unclear (I didn’t look) but the number is indeed valid.

As for the proposal: I also support it.

I would consider this suggestion a malicious edit. A mapper has gone out of their way to add context and this is just trying to delete it.

1 Like

I had seen that and wasn’t quite sure how to handle it. It’s similar to emergency numbers (999, 112, etc.), in that there’s a question as to whether they should actually be tagged on an object, since such numbers are not the way to contact a place.

I agree that the edit should not be made as shown, but it is certainly appropriate to flag such issues somehow, since it could show something that needs to be improved. Perhaps here, the sixth form should have a separate POI? Or there’s another one where a golf course was listing two numbers, one for the club and one for the pro shop, again, more detailed mapping is needed.

On the other hand, w321333846 (here) has phone=+44 1506 829 580 "ward 1";+44 1506 829 893 "ward 2" and the numbers in the quotes make it not parse correctly at all.

If a number can only be called from the UK then it should be tagged phone:GB see Key:phone - OpenStreetMap Wiki

3 Likes

TBH I do not care what an arbitrary third party library thinks of the way we’ve tagged the numbers. We’ve been using quotes for comments in e.g. opening hours for years and they seems perfectly fine for explanatory notes in phone numbers to me.

However, the use of quotes in opening hours is both documented and widely used, in contrast to phone values. However, this is tangential to the topic at hand of the automated edit, so perhaps should be split to a separate thread.

3 Likes

I am treating this proposal as approved, as I have heard no objections to the automated edits. I therefore plan to enable the bot for the UK starting from the run early on the morning of 12th December, as per the timescale given in my original post.

3 Likes

Now all issues you see here

are ones that the bot will not fix.

Of particular interest are the invalid ones, which may be missing digits, have extra digits or have a typo that gives them an invalid area code.

1 Like
https://api.whatsapp.com/send?phone=x

Seems like that one could be automated?

I’m not convinced 999 on a defibrillator is an error.

1 Like

I’m not convinced 999 on a defib helps anyone.

My negative about this would be bumping the last modified on a bunch of old data, it makes me sad.

https://api.whatsapp.com/send?phone=x

There aren’t very many of those, but there are very many ways that there can be WhatsApp URLs, take a look through taginfo. So I don’t really think it’s worth the effort to add special checks for, but I’m open to contributions.

I agree that 999 on a defib doesn’t quite seem right. I feel like the phone tag is generally for contacting the object an OSM element refers to.

Yes, this has led to elements being modified, but that has essentially all been done already. Going forward, it will only catch newly created or edited elements.

I’m a little unsure why some are fixable and some are invalid, e.g., North West

+44 1606 288828 (Local Tourism); +44 300 123 8123 (Council Services)

Is listed as fixable but

+44 1606 784881 (between 11am and 9pm)

is invalid.

Seems like the number is fine, just needs the text in the parenthesis removed - like with some other examples. Shouldn’t this be auto-fixed?

Ahhh, or is it because it has numbers in the text?

It is because of the numbers in the text.

I split the numbers by various separators (fixing where e.g. comma or slash is incorrectly used) then do little processing other than giving it to libphonenumber-js and seeing what comes out.

The demo here is good for testing it.

As above though, it’s not clear whether text should be removed, or maybe description be used or separate POIs created, depending on the situation.

If 999 are the contact to get the code to open the lock on the cabinet then it probably is the correct contact number for that amenity?

This document suggests that many have this arrangement:

Public access defibrillators are usually kept in cabinets in prominent public locations with signage to help people locate them. Some cabinets are unlocked, some are locked and require a code. The ambulance service will give this code to the person who makes the initial 999 call once they have confirmed that they are dealing with a cardiac arrest nearby.