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.sm...@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 <zhoum...@icloud.com> wrote: >> >> >> I’m using Google’s libphonenumber <https://github.com/google/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.sm...@xs4all.nl >>> <mailto:colin.sm...@xs4all.nl>> wrote: >>> 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? >>> >>> >>>> On 07/06/2022 09:45 Marc Zhou Toneu via Talk-nl <talk-nl@openstreetmap.org >>>> <mailto:talk-nl@openstreetmap.org>> wrote: >>>> >>>> >>>> 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 >>>> <https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator>, 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 >>>> >>>> >>>> >>>> >>>> >>>>> On Jun 7, 2022, at 09:15, Maarten Deen <md...@xs4all.nl >>>>> <mailto:md...@xs4all.nl>> wrote: >>>>> 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 >>>>>> <talk-nl@openstreetmap.org <mailto:talk-nl@openstreetmap.org>>: >>>>>> >>>>>> >>>>>> 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 >>>>>> _______________________________________________ >>>>>> Talk-nl mailing list >>>>>> Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org> >>>>>> https://lists.openstreetmap.org/listinfo/talk-nl >>>>>> <https://lists.openstreetmap.org/listinfo/talk-nl> >>>>> _______________________________________________ >>>>> Talk-nl mailing list >>>>> Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org> >>>>> https://lists.openstreetmap.org/listinfo/talk-nl >>>>> <https://lists.openstreetmap.org/listinfo/talk-nl> >>>> >>>> _______________________________________________ >>>> Talk-nl mailing list >>>> Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org> >>>> https://lists.openstreetmap.org/listinfo/talk-nl >>>> <https://lists.openstreetmap.org/listinfo/talk-nl> >>
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
