[OSM-talk-nl] Bot Phone Number Formatting Proposal

[Marc Zhou Toneu via Talk-nl]

To whom it may concern,

I’ve recently written a pythons script that would automatically format the phone numbers in NL should it be wrongly formatted, and I would like to hear your opinion about it.

So far I am proposing to do the following:

• Formatting phone numbers according to the ITU-T E.123 format pattern
• Phone numbers that were not parsable would be left untouched
• Phone numbers that do not need formatting would be left untouched

There were some edge cases that I’ve seen so far such as:

• Having URL links or opening times as phone numbers
• Having ‘/‘ for indicating multi value tag
• Phone numbers but with description as part of it, such as ‘10ct/m’ or ‘emergency’

Phone numbers that would require manual inspection/correction such as the following will be send to map roulette:

• Phone numbers belonging to other countries
• Phone number values that is just completely wrong

Please let me know if you have any concern or objections about it, and I’ll gladly take your feedback into account.

Kind regards,

Marc

[Marc Zhou Toneu via Talk-nl]

Hi all,

Just a follow up from my initial email, I do intend on expanding the scope of the tags including contact:phone, contact:mobile, fax and contact:fax once that the bot has proven that it is able to correctly format the phone numbers.

Kind regards,

Marc

[Maarten Deen]

Do you have a link to your script and maybe some examples of phone numbers that need correcting?

Regards,

Maarten

Op 06-06-2022 21:11 schreef Marc Zhou Toneu via Talk-nl <tal...@openstreetmap.org>:

_______________________________________________
Talk-nl mailing list
Tal...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[Marc Zhou Toneu via Talk-nl]

Morning,

Here is a list of some of the nodes that would require a manual correction:

• 2796279335: '+31 499 475415;toets 1 voor spoed'
• 2818035695: '+31 6 165 567 969’
• 2818064864: '+31 65397447’
• 2824141858: '+31 13 522 09 72 "emergency”'
• 2824141869: '+31 13 522 09 72 "emergency”'
• 2824142102: '+31 13 528 6060 "Algemene spoedljn OisterwijkKliniek"’
• 2853116449: '+31 0162 – 242 006 of +31 06 – 421 27 994.’
• 2853564877: '+31 01620 456 790’
• 6176636305
• 2862917377
• 2724284582
• 34206650: '09002357275 13ct/m’

One question regarding to have phone number description in the phone tag though, are we allowed to have description in the phone tag other than the actual phone number? I couldn’t find any conventions about it.

Vast majority of bad phone tag values are either not following the proper syntax of separation of multiple values in one tag, invalid phone tag value such as invalid number or having the contact:website value as the phone number.

Example of nodes that would need format correction (there are thousands of nodes that would require format correction):

• 1653511382: '+31 (222) 319 309'  ==>  '+31 222 319 309'
• 821734360: '+31 297 324548;+31 172 508360'  ==>  '+31 297 324 548; +31 172 508 360’
• 520290181: '0204276833'  ==>  '+31 20 427 6833’

I am still working on the script, it’s expected that I will be done with it later today or tomorrow. I’ll let you know when I’ve created a repo for it.

Regards,

Marc

[Colin Smale]

You will need to be careful with (most) 08/09 numbers in the length check as you cannot determine algorithmically what the length should be. Although these numbers are not (normally) dialable from outside the country it's still a good idea to put them in E.164 international format. Like that, if you try to dial the number while you are in France for example you will get an error tone rather than a random French person.

The number '+31 01620 456 790’ could IMHO be safely corrected automatically - the extra "0" is a common mistake, the intention is pretty clear and ignoring the "0" yields a valid number.

Are you able to distinguish between 2-digit and 3-digit area codes?

[Marc Zhou Toneu via Talk-nl]

(Just realized that I’ve only replied to Colin without cc’ing the mailing list, here’s the reply that I’ve sent to him earlier.)

I’m using Google’s libphonenumber library to parse and format the phone numbers, and based on the test results it’s looking really promising. I’ve attached a screenshot showing more examples of format correction.

In regards to numbers with prefix of 08 or 09, all I’m doing is formatting the original tag value, so the worst case would be either the script failed to parse the phone number and leaves it untouched, or added/removed format spacing. Either case, the end user would still be able to manually dial the phone number if it goes wrong. We’re safe to truncate the leading 0 when dialing domestic number in the international format either way.

[Marc Zhou Toneu via Talk-nl]

Hi Colin,

NL-NB is for the whole Brabant province, but I would gladly do a quick test for the whole NL in a bit and send it to you in CSV.

To your second question, I’ve implemented that line of code to generalize dealing with single and multi value tags to make my life easier, but essentially yes, vast majority of the multi-value tags would need format correction according multi-value separation convention. This section of code would also prevent updating a node when there is no need to, because as far as I’m aware OSM’s node update endpoint does not check if version n and version n+1 is the same or not, so we’re risking incrementing a node’s version when there is no need to.

Regards,

Marc

On Jun 7, 2022, at 11:52, Colin Smale <colin...@xs4all.nl> wrote:

Hi Marc,

Aah, that sounds ok. Will you do a wider sample, instead of just around Tilburg? I would be happy to review the results, if that would help.

In your script, I guess the following code is trying to say "update the tag, but only if any of the phone numbers have been changed". Won't that always be true where there are multiple numbers, given the difference between ';' and '; ' (i.e. the extra space after the semicolon)? I'm not a native python-speaker so I may be missing something here.

<image.png>

What I do have, is a quite a bit of experience with parsing and (re)formatting phone numbers across the whole world, although by doing it the "hard way" and not by using libphonenumber. Feel free to reach out if I can help at all.

Regards,

Colin

On 07/06/2022 10:57 Marc Zhou Toneu <zhou...@icloud.com> wrote:

I’m using Google’s libphonenumber library to parse and format the phone numbers, and based on the test results it’s looking really promising. I’ve attached a screenshot showing more examples of format correction.

In regards to numbers with prefix of 08 or 09, all I’m doing is formatting the original tag value, so the worst case would be either the script failed to parse the phone number and leaves it untouched, or added/removed format spacing. Either case, the end user would still be able to manually dial the phone number if it goes wrong. We’re safe to truncate the leading 0 when dialing domestic number in the international format either way.

<Screen Shot 2022-06-07 at 10.48.59.png>

On Jun 7, 2022, at 10:39, Colin Smale <colin...@xs4all.nl> wrote:

[Marc Zhou Toneu via Talk-nl]

As agreed, I’ve attached the CSV file to this email.

[Marc Zhou Toneu via Talk-nl]

Morning fellow mappers,

I’ve just uploaded my script to my repository, do note that I’ve removed the section of the code responsible for uploading modified data back to OSM, I will put the code back when the script is ready to be deployed.

Regards,

Marc

On Jun 7, 2022, at 15:21, Marc Zhou Toneu via Talk-nl <tal...@openstreetmap.org> wrote:

As agreed, I’ve attached the CSV file to this email.

<test.csv>