Announcing a new phone number validator

General talk
, , ,
1

I’ve made a website to find invalid[1] phone numbers in OpenStreetMap data, to make it easy to fix them.

I’ve been through a lot of the UK and South Africa (places I am familiar with) and fixed a lot of the numbers that can be fixed remotely, and thought that others might like to do the same for their region. I’ve included a couple of other countries for now and I can easily add more, just let me know.

The data should update once per day using overpass. For technical details, see the GitHub repository, if you spot any issues let me know either here or there.

The usual comments about data validators apply, do not just make changes because this tool says that something is wrong, verify using other sources where appropriate. Sometimes a ‘suggested fix’ is shown, these can be helpful but are not always appropriate. Some things shown as errors here will not actually be errors or will highlight other data issues.

  1. Invalid includes numbers that are not in ‘international’ format, meaning without the country code, numbers that have too many or too few digits, values which contain other words and other issues detected by the libphonenumber-js library. ↩︎

5 Likes
2

Italy - 5.74%. Countless miss the intl prefix. Have a phone number formatting plugin for JOSM, fixes that issue and formats according to what’s referred to as E123, so offering a number like 0871234567 will turn it into +39 0871 123 4567 and does this both for phone and fax, then actually prefixing contact: to the key. 5 and 6 digit numbers like 123 456 it will contract to 123456. Mobile nrs it doesn’t (yet). Integrated into the over JOSM validator process so if you’ve loaded an area all you need to do is hit Shft+V and it works thru the whole dataset, then select the phone error line and fix button and that can be fixed will be. On your prompt just did that and fixed 9. \o/

PS the plugin taps into some oogle database so it must be working according the country specific rules wherever you map.

1 Like
3

This can do the same thing (using the same library) and then gives a link to apply the fix in JOSM. I agree that for fixing large numbers of elements (7496 that can be fixed like that in Italy) that this may not be the best tool, and that wasn’t how I fixed most of the ones in the UK and South Africa. But once the easy ones are done it’s then easier to find the actual errors, like where someone missed out a digit or added an extra digit.

However, my website keeps the phone tag wherever it was (not changing to contact:), unless it’s a non-mobile number in the (contact:)mobile tag and doesn’t suggest any changes which are simply cosmetic (adding or removing spaces).

4

This looks like a useful tool – glad you took the time to put it together. Is the country.json only for segmenting the report by region, or does it have some effect on the validation too?

1 Like
5

Wasn’t there already a tool for this? Or did I glitch through a matrix—from a universe where the tool was easily accessible by searching for something like phone: on the OSM Wiki to a universe where that tool never existed? :thinking: Because I don’t remember the URL, and I cannot find the URL anywhere on the wiki—if my life depended on it, I would have been dead.

6

Thanks to @Javnik Poland is there as well now (with a bit of work to do!).

Is the country.json only for segmenting the report by region, or does it have some effect on the validation too?

It is firstly for segmenting by region, but the country code in there is used to check and validate numbers and also I can add exclusions on a per country basis. e.g. in France, post offices seem to all have the phone number 3631 and this is apparently valid, so that’s excluded from the check.

Below country level it’s just to separate the data by region and make the overpass queries not too big.

Wasn’t there already a tool for this?

I don’t remember coming across a dedicated tool, other than JOSM validators and old Maproulette challenges.

7

Hm OK, I guess the whole NANPA would be one report then, unless we have some way of segmenting by area code. Area code boundaries unfortunately don’t necessarily align with anything at all.

8

Well it’s just for the display of the reports that it’s segmented like that.

If you’re interested in adding something, I would suggest to just start with one state, perhaps. Other states can be added as there is interest.

1 Like