Proposed automated edit of phone numbers

Communities Switzerland
1

This follows on from Telefonnummern-QA

Motivation

Phone numbers keep being added to 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 months 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 Switzerland to reformat phone numbers which have extra punctuation or are missing the country code to international phone format, including the country code and with spaces in the number.

This automated edit has already been discussed and accepted in the US, UK and Canada 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, 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 Swiss country code
  • The new number is a valid phone number
  • The new number is a Swiss number with +41 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

Today there are only 3 elements with invalid numbers, as all other invalid numbers have been fixed in the recent months. There seem to be typically 2 or 3 new invalid numbers per day.

Grouping of Edits

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

Examples of edits that would and would not be made

Edits that would be made automatically by the bot

https://www.openstreetmap.org/node/577982928: phone=0564965443 to phone=+41 56 496 54 43

https://www.openstreetmap.org/node/1193865481: phone=0564965655 to phone=+41 56 496 56 55

Edits that are suggested by the website but not made automatically

I don’t have any specific examples right now, as everything has been cleaned up. But anything with multiple phone numbers or with text appearing would have suggestions but not get fixed by the bot.

Objects not detected as issues

https://www.openstreetmap.org/node/8488484967: phone=+41793307032

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

Timescale

I will wait at least 10 days, until 2025-12-26, for any comments before commencing this edit. The proposal will also be shared to be posted in weekly OSM.

Wiki Page

1 Like
2

As said in the other thread; looks good to me based on the mentioned conditions/flowchart.

3

Good thing.

Checking possible formats, the one you use is better than "+41 (0)56 496 54 43”. I would include adding spaces to “+41793307032“

1 edit per canton and per week might be sufficient.

4

Thanks for the comments. However, I don’t think it’s worth doing just reformatting of phone numbers. As long as it’s valid, data consumers may be likely to reformat before displaying to users (they need to remove spaces to make it into a valid tel link anyway).

I could have a look at changing the schedule, but at the moment the process runs every day to scan for invalid numbers and create the website, and so the bot edit just tags onto that. This way the elements get fixed as soon as possible and the bboxes are likely small as there is often only one element.

5

I think to run it once a day is fine, even though it might only change very few numbers every time, If it runs once a week there will be more numbers that might be fixed by the bot - but during the time they are open they draw the attention of the humans away from the things they can and should fix. So part of the advantage with the bot-edits is gone.

Just reformatting is really not worth the “work”, one just does it to make it look nicer and easier to read - but it is not a mistake or problem in the data.

1 Like
6

So would it change formatting by removing punctuation or rearranging spaces? I noticed some users doing that. None of this affects actual use, but may improve readability.

7

Based on a current suggested fix of n10573578460

Any of:

+41 (0) 91 923 84 22

+41091 923 84 22

+41 91.923.84.22

+41 919-238-422

Would be changed to +41 91 923 84 22

And any of these would not be edited:

+41919238422

+41 9 19 23 84 22

+419192 38422

+41 9 1 9 2 3 8 4 2 2

1 Like
8

I don’t really understand why you would change readable formats like:
+41 91.923.84.22
+41-91-923-84-22

but not unspaced or weirdly spaced formats.

Another one that could be fixed is:
41919238422

[edit: that last format somewhat gets generated in my spreadsheet, all samples are correct in OSM, nevermind]

1 Like
9

The documented format for phone numbers in OSM has for a long time allowed spaces as separators but nothing else. I was not proposing to ‘fix’ different space usage as I thought that such changes would be more likely to be opposed, as they basically needlessly update the last edit date and increase the version number. This is partly because my background (not Switzerland) is such that there is no single expected spacing format for phone numbers. I made up all of the spacing examples above, I have no idea how common unusual spacing is.

41919238422 would be changed, as it is missing the leading plus.

10

I’d say that specific spacing (or “.” / “-” instead) is expected for “+41” numbers.

One could argue that your reports and bot leads to “basically needlessly update the last edit date and increase the version number” when they replace “.” or “-”.

11

AFAIK the expected format of phone numbers in Switzerland does not include dashes or dots.

12

It’s not really incorrect (or worse) than having spaces at random places.

13

Actually these special signs are “wrong” or at least so uncommon that you can not expect a tool consuming swiss phone-numbers to filter them. So taking them out is good for the data quality.

About the spaces at random places I can only agree in parts: Yes we usually write phone numbers like this +41 xx xxx xx xx and everything else looks strange to us, but in fact there are phone-numbers written with a different spacing just to make them easier to remember. Just one number I looked up now: Alarm: 1414 | Schweizerische Rettungsflugwacht Rega

+41 333 333 333

Of course one could also memorise +41 33 333 33 33, but the way the Rega shows it is much easier.

1 Like
14

“Actually these special signs are “wrong” or at least so uncommon that you can not expect a tool consuming swiss phone-numbers to filter them”

Works fine on my phone. Do you have some custom Swisscom phone ?

15

I feel like the only opposition I have here is that the edit doesn’t go far enough, so I plan to enable the bot from tomorrow’s run, with only the formatting done as originally discussed, not changing anything where it would only affect spaces.

16

No real reasons were given why some reformatting is done but not others. “We always remove it” isn’t really helping.

So it’s better to have the bot focus one fixing actually broken numbers (missing “+”, "41”) and discontinue the reports for others. As you mentioned, anything else also increases the version numbers.

17

I guess my best reason is that the wiki documented format is for international format with spaces only and I see no good reason to have other formats and require data consumers to deal with them.

Probably irrelevant that such numbers are probably very rare. I don’t have any data on that as everything has been fixed already, so it would only be anything new that comes up.

18

Maybe I’m confusing something or you are confused, but the document notes formats in spaces and with “-” which is almost the opposite what you are trying to do.

Also, if you are not sure what you may have edited or will actually be editing, I think it’s preferable you stick to automated edits limited to adding “+”, “41” and/or removing a leading “0”.

19

My reading of the wiki is that spaces are preferred as separators, but that dashed are used in North America (NANP), by convention and consensus. This has been on the wiki for a very long time, so seems to reflect community consensus.

On your second point, what I had meant was that many edits were made before the bot was enabled, not by myself, so I don’t have an idea of how commonly people map phone numbers with other spacing. Since the bot has been enabled it has fixed some other space characters, a few missing country codes and a leading zero in brackets after the country code.

20

Presumably you know what goes into the report you are generating and what gets fixed.

A simple way to solve this could be to look into a local phone book and check what format they are using and just adapt that. If it uses 0NN NNN NN NN, let’s go for +41 NN NNN NN NN. If it uses “-” or spaces at random places, that would go. Either would be in line with Key:phone afaik.
If some special thing comes up for a single number (and we actually have it in OSM), it can go into Key:phone:mnemonic .
Unfortunately, I discontinued receiving phone books a few years back. Can somebody else have a look?