Morning fellow mappers, I’ve just uploaded my script to my repository <https://github.com/SirTypesALot/OSMPhoneNumberFormatter>, 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 > <talk-nl@openstreetmap.org> wrote: > > As agreed, I’ve attached the CSV file to this email. > > <test.csv> > > >> On Jun 7, 2022, at 12:10, Marc Zhou Toneu via Talk-nl >> <talk-nl@openstreetmap.org <mailto:talk-nl@openstreetmap.org>> wrote: >> >> 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 >>> <mailto: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 >>>> <mailto: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 <mailto:Talk-nl@openstreetmap.org> >> https://lists.openstreetmap.org/listinfo/talk-nl > > _______________________________________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-nl
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
