Note: I am happy to use the translate button for your replies.
I have a site that detects issues with phone numbers in OSM data and I recently added Brasil to it.
52258 issues were detected, 43% of all phone numbers tagged in Brasil. Many of these are because of one or more hyphens being used to separate parts of the number. Other issues include missing country codes or words in the text.
I have an ongoing automated edit of phone numbers running in other countries which fixes basic formatting issues and I would like to propose extending this to Brasil. Should hyphens be permitted in phone values, despite the global consensus being largely against them?
As of today, the edit would target 44305 of the âsuggested fixesâ on the website, with those excluded mainly being values with multiple numbers or any text in the tag value. I can provide a list of the exact edits if that would be helpful.
Additionally, it would perhaps be good to split the report into smaller areas to make analysis easier, however the admin relations in Brasil do not appear to be properly nested as in other countries so it was difficult to work out which subdivisions belonged to which larger division.
Muito bacana a sua ferramenta e eu a princĂpio nĂŁo me oponho a correçÔes massiva. Entretanto creio que a ferramenta esteja apontando como erro o que na verdade aqui estaria correto. Acredito que a comunidade nunca tenha discutido o tema, porĂ©m o usuĂĄrio @portalaventura fez a padronização toda com hĂfen principalmente no estado do RS, sem ter havido posicionamento contrĂĄrio na Ă©poca, conforme documentado em Rio Grande do Sul/Controle de Qualidade - OpenStreetMap Wiki.
Talvez seja bom consultar a comunidade para ver qual padrão utilizar. Discussão seguida de votação.
NĂŁo compreendi o que quis dizer com âhowever the admin relations in Brasil do not appear to be properly nested as in other countriesâ. Qual o padrĂŁo que estaria sendo usado em outros paĂses e que estaria faltando aqui? cc @Fidelis_Assis
Obrigado por trazer o tema ao FĂłrum.
1 Like
Hello, my name is Francisco Neto .
Iâm an OSM user in Brazil.
I suggest that, for this matter of user identification (by mobile phone number), the E.164 standard be used.
https://www.itu.int/rec/T-REC-E.164/
Reason: It is the international standard that identifies the country, location, and terminal.
2 Likes
A discussion and would be a good idea, I will do that. Using a mixture of hyphens is not very usual elsewhere.
The relation for Brazil has as subareas Southeast Region (level 3), South Region (level 3) etc. but also Alagoas (level 4), GoiĂĄs (level 4) etc.. Should those latter ones not be subareas of their respective regions?
Thank you, what exactly do you understand by this? I think that E.164 describes the structure of the number, but not how it should be written down. Some people mean by this to write numbers with no separators at all, which I think makes it much harder for mappers. Compare +55 49 3674 0438 to +554936740438.
Probably, but the level 3 areas are not admin regions, so perhaps itâs why the level 4 areas are subareas of the country (but Iâm no expert on that). Anyway, itâs probably a better idea to consider the level 4 areas (states), itâs more granular and people are more used to that (you can put inside the regions if you want, doesnât look weird).
2 Likes
As already pointed out by @matheusgomesms, the admin_level 3 areas, despite being mapped as administrative boundaries, they are not administrative, but statistical. Probably it was a misinterpretation back then and there have been discussions on changing them to statistical as well as for the admin_level 5 and 7 areas, which are also not administrative. So, I donât think we should enforce that by adding then as subareas. Changing them to statistical areas seems a better option to me.
Another reason that suggests not using subareas is the fact that, as noted in the wiki, they are
*Optional, disputed[1], and redundant (references to sublevels may also be found with spatial queries, provided that thereâs no overlap between similar subdivisions). Also referencing other relations makes editing more complicated in some cases.
[1] The Subareas have been entirely removed from the United States by community consensus*
2 Likes
Agreed. Spaces make it clearer and are the recommended separator in E.123. Although hyphen can be used if agreed upon on a country, for some reason, a standard international format should preferably be used in OSM, in my opinion.
1 Like
The website now shows reports by states instead of by regions.
This indeed shows the regional variation in number formatting, but even with states there is variation as to using some hyphens and some spaces, only spaces or only hyphens.
It seems the toll-free numbers are not working as intended:
It shouldnât suggest the removal of the initial 0.
Also this one: 4000 to 4009 numbers should not have code area, so only the country area should be added (itâs not suggested here the +55).
That surprises me, you think that +55 0800 720 1111 is correct and valid? Or do you mean that it should be 0800 720 1111?
This is a shared cost number, are such numbers reachable internationally?
The current logic is that if it is a special cost number (free, shared cost, premium rate) then it will be considered valid either if it does or does not have a country code, however it is currently mapped. And then if thereâs anything âwrongâ with it, like brackets or hyphens, then itâs fixed, respecting whether or not it had a country code before.
From my brief research, shared cost and free to call numbers will still work if dialled with a country code in Brazil (but will likely fail to connect when dialled from abroad), so I could probably switch to enforcing a country code.
