Een paar dagen terug stuitte ik op deze tool om foutieve telefoonnummers op te sporen (verkeerde opmaak, onjuist aantal cijfers, etc). Momenteel hebben we in Nederland geen verkeerd geformatteerde telefoonnummers, doordat anderen ook via deze tool de formatting corrigeren (of gebruiken voor opsporing van). Bijvoorbeeld vanmorgen: 13759540311 en 13725105506.
Voor dit soort simpele edits, kan in de tool ook worden aangezet dat dit in NL automatisch gaat via een bot account. Dit gebeurt momenteel al in zeven landen (USA, UK, Canada, Duitsland, Zuid Afrika, Oostenrijk, Zwitserland).
Voelen jullie er iets voor als ik contact opneem met de maker om dit ook voor NL aan te zetten? Zouden jullie liever een uitgebreide proposal zien zoals deze ook is gemaakt voor o.a. DE?
Eventueel kunnen we het ook nog over de exacte formatting hebben, gezien wij in NL volgens mij <landcode><spatie><netnummer><spatie><overige cijfers> aanhouden. Deze tool zet nog een spatie tussen de overige cijfers. Zoals ik de andere topicâs lees zou dit aangepast kunnen worden per land (bijv in USA zetten ze - tussen de getallen).
Van mij mag je je gang gaan, graag zelfs, maar doe vooral geen moeite om spaties te corrigeren. Dat is tijdverspilling en een nutteloze versie update van OSM objecten.
+<landcode><spatie><netnummer><spatie><abonneenummer> is het juiste format. Dus spaties tussen de onderdelen van het telefoonnummer. Dit soort tools voegen (net als in je voorbeeld) wel eens leesbaarheidsspaties in het abonneennummer toe, maar die zou ik weglaten.
Voor het automatisch verbeteren voel ik wel iets. Daartegenover staat dat dit vaak POIâs zijn die door beginners zijn toegevoegd met meer fouten (openingstijden-syntax, POI niet op adresnode, etc.). Dat mis je met automatisch verbeteren.
Precies & om het compleet te maken deze NL formatting in een note er automatisch bij laten zetten want anders komt er een Amerikaan met zijn ander soortige formatting tool de zaak weer onnodig verkeerd omzettenâŠ
Ik geef de voorkeur aan handmatig. Het zijn er op dagbasis maar een beperkt aantal. En, zoals bijvoorbeeld bij 13759540311 stond deze ook nog net verkeerd en ontbrak de overkapping.
Ik verwerk ze in JOSM en vang zo ook nog wat âfoutmeldingenâ af.
Daarnaast werkt de automatische aanpassing, voor zover ik kan zien, alleen voor de meest simpele gevallen.
P.S. Ik ben er ook al eens tegenaan gelopen dat het nummer van een hoofdkantoor o.i.d. was gebruikt in plaats van het nummer van de locatie.
Ik weet niet of hierover afspraken zijn gemaakt maar de versie met ook nog een spatie in de overige cijfers bevalt mij beter (makkelijker leesbaar). Afhankelijk van de lengte van het kengetal/netnummer splits ik de overige cijfers in 3+3 of 3+4.
Edit: P.S. En ook de nodige samenvoegingen van POI en adres node (als eggie me daarbij niet voor geweest is
Het wordt gelukkig niet als fout gezien om niet de 3+3 of 3+4 constructie aan te houden. Alleen als er een andere fout in zit zet die het zo neer.
Ik probeerde het nog terug te zoeken, maar ik kon inderdaad alleen jou terugvinden die dit gebruikt
Duidelijk! Het lijkt inderdaad mee te vallen om hoeveel gevallen dit gaat. Dan laten we het lekker zo en voeg ik dit topic toe aan de wiki voor naslag.
Wat is het nut van die spaties? Om te zien wat het landnummer en netnummer is? Dat is tegenwoordig toch helemaal niet interessant meer? Als je mobiel belt (99% van mijn telefoongesprekken) moet ik het netnummer er toch bij zetten.
Maar goed, als dat de afspraak in Nederland is, no problem. Ik was gewoon nieuwsgierig waar die opmaak vandaan komt.
En eigenlijk is dat zelfs taggen voor de renderer/gebruiker⊠met een reeks cijfers die een telefoon nummer representeren kan elke app laten zien wat ze leuk vinden. Of dat dan 0612345678 wordt, of +31612345678 of +31 (0) 6 123 4567 8 zal mij een worst wezen ÂŻ\(ă)/ÂŻ
Yep, maar die nummers worden niet ingevoerd (en gecheckt) door je mobile maar door ons arme humans. En dan kan het toch behoorlijk handig zijn als er wat spaties in zitten .
Ik wil ook wel een telefoonnummer toevoegen op basis van websites en was het zat ze dan handmatig om te zetten in het goede formaat, dus maar een python script geschreven op basis van:
Sterker nog liever in detail 1 ding automatisch goed gecorrigeerd en daarna volgend thema automatisch goed gecorrigeerd want dat werkt standarisatie waar dat goed mogelijk is in de hand.
Later kun je (als alle afzonderlijke automatische correctie âscriptsâ goed bleken te werken) kijken of je de afzonderlijke goed werkende scripts op verschillende onderwerpen kan bundelen zodat ze in 1 keer meerdere soorten auto-correctieâs tegelijkertijd uit kunnen voeren als verdere optimalisatie stap.
Andriod gebruikt zoiets onder de motorkap, de Python library is niet voor niets gebaseerd op
Googleâs libphonenumber:
What is it?
Googleâs common Java, C++ and JavaScript library for parsing, formatting, and validating international phone numbers. The Java version is optimized for running on smartphones, and is used by the Android framework since 4.0 (Ice Cream Sandwich).
Even gekeken en ja op mijn telefoon worden telefoonnummer zo weergegeven als ik ik mijn eerdere bericht heb aangeven en zoals het dus ook uit het python script komt.
Ik weet wel dat Josm onder âOther Testsâ een bericht geeft âTelefoonnummer niet in E.123 formaatâ en als ik dan het telefoonnummer door mijn pythonscript haal dan is dat bericht weg.
Josm geeft niet de optie weer om het te corrigeren hoewel dat volgens mij wel redelijk makkelijk zou moeten kunnen, als je weet dat het fout is dan zou dezelfde software ook het goede formaat moeten kunnen ophoesten.
Geen gek idee om daar voor Josm een issue voor te openen.
Nu we het toch over de Josm validator hebben, ook de âConditional restriction can be prettifiedâ waarschuwing zou wel zân auto-correct kunnen gebruiken, wel eens gekeken maar geen idee hoe dat prettify-en er dan zou moeten uitzien.
De fijne details ken ik niet, maar de opening_hours evaluation tool die ik gebruik (ook voor de tijdgebonden waarden bij access:conditional) wijzigt in ieder geval spaties, hoofdletters en voorloop 0-en.
