Das sehe ich anders. Ich nutze oft Angaben in Apps, um direkt daraus einen Anruf zu starten. Maps.me z. B. lässt die Telefonnummern wählen. Eine so verwertbare Angabe halte ich dafür wichtig. Für Flyer etc wird ja wohl niemand die Nummern aus OSM ziehen.
Das fände ich schade. Sich voll auf die Ausgbe des Tools zu verlassen, ist wohl in die Hose gegange. Wenn ich dich ganz oben richtig verstanden habe, dann hast du aber doch eh schon eine Review-Möglichkeit vorgesehen. Natürlich dauert es wesentlich länger, jeden einzelnen Änderungsvorschlag zu validieren, aber auch kleine Korrekturen sind IMO besser als gar keine.
Daher würde ich dich schon ermuntern, das prinzipielle Vorgehen vielleicht noch etwas zu tunen und das Tool für mehr Benutzer nutzbar zu machen.
Jo, der Validator wäre ein Anfang. Hab mal reingeschaut und es stimmt, er kann es noch nicht.
Nachdem ich mir die E.164 mal näher angesehen hab, hab ich doch davon Abstand genommen. Einfach ist die nicht. Und das Wiki ist für mich als “Sekundärliteratur” hier nicht relevant.
An die logische Weiterentwicklung (Test der Werte bei der Eingabe und evtl. Verbesserungsvorschläge) trau ich mich eh noch nicht ran.
Okay, stimmt, die Direktwahl aus Apps heraus ist sicher eine Sache, die häufiger vorkommt und bei der man als Nutzer nicht unbedingt die Möglichkeit, hat, das zu korrigieren, wenn es falsch aussieht. Allerdings fällt das dann u.U. trotzdem unter den Hinweis, dass dann die Betreiber dieser App sich beim Ziehen der Daten dafür sorgen sollten, dass sie aufbereitet werden. Da dies automatisch erfolgt, wird ein Tool vermutlich nur diejenigen Einträge korrigieren, bei denen sicher ist, dass sie inhaltlich korrekt überleben und die restlichen Einträge so lassen, wie sie sind.
Das Tool von ENT8R – ich habe es nicht gesehen/probiert – sollte am vielleicht alle Einträge mit Original und Korrektur in einer langen Liste aufführen und zu jedem Eintrag eine Art Confidence-Level berechnen. Also wie ich oben schon sagte: 100% heißt: Das Tool ist sich sicher, alles richtig gemacht zu habe, 0% heißt: Das Tool kann mit der Angabe nichts anfangen. Und dazwischen vielleicht noch 25, 50 und 75% oder einfach nur 50%. Dann kann man als User durchgehen, ggf. sortiert nach Level, und das alles überfliegen. Selbst 6000 Einträge sind auf diese Weise irgendwann abgearbeitet. Wenn man dann noch direkt in dieser Liste manuell korrigieren kann … Um die Sache noch zu vereinfachen, kann man in den Werten noch Dinge machen wie eine farbliche Hervorhebung der drei oder sogar vier Komponenten, damit man auf einen Blick sieht, was von der Originalnummer als Landes- Orts-, Nummern- und ggf. Durchwahl-Teil verwendet wurde. Feinheiten, die je nach “optischem Typ” des Nutzers mehr oder weniger sinnvoll sind.
Kurzfristig sollte es mindestens einen Validator geben – zumindest JOSM hat offenbar keinen, bei iD weiß ich es nicht. Darüber hinaus sollte es eine vernünftige Maske geben, in der man die vier Komponenten eingeben kann. Bei JOSM lassen sich die Presets leider nicht dafür verwenden, soweit ich weiß, da damit nur einzelne Eingabefelder auf einzelne Tags gemappt, nicht aber mehrere Felder nach Schema X zu einem konsolidierten Tag-Wert verknüpft werden können. Oder geht sowas?
Darüber habe ich auch schon nachgedacht… Ich glaube das würde sogar klappen…
Die Bibliothek, die ich zum korrigieren der Nummern benutze (https://github.com/googlei18n/libphonenumber) hat jedenfalls die Funktionen
isPossibleNumber()
und
isValidNumber()
was sich schon einmal vielversprechend anhört.
Okay. Nach dem ganzen Feedback und Vorschlägen werde ich es doch nochmal aus der Tonne holen
Hi … habe das Tool jetzt mal genutzt um rund um meine Homebase in NRW “aufzuräumen” und … es hat ganz prima funktioniert. Danke!
Da ich die Faxnummern (und davon scheinen noch jede Menge eingetragen zu sein) gleich mit bearbeitet habe, war doch noch ein wenig Handarbeit nötig.
Die Normalisierung der Telefonnummern hat bis auf einen Fall (eine Ausgangsnummer die nur mit 49 startete) immer geklappt.
contact:phone hattest du ja nicht abgefragt, oder?
Werden auch nummern gefunden, die direkt an Objekten (Haus) erfasst sind?
Hilfreich wäre noch, wenn man innerhalb einer Abfrage erkennen könnte, welchem man schon bearbeitet hat (Editor aufgerufen) und welche nicht).
Grundsätzlich könnte man das Script immer mal wieder brauchen, falls andere User neue Einträge mit einem anderen Nummernschema erfassen.
Danke nochmal und Gruß
Stephan
P.S.: Mit über 9000 Einträgen für NRW scheint Maproulette andere Selektionskriterien zu haben als dein Script … und es bekommt scheinbar die Änderungen an Maproulette “vorbei” nicht mit (bei einem kleinen Test: hat mich heute auf einen Eintrag geschickt, den ich gestern schon gefixed hatte)
Genau, ich hab mich ersteinmal auf phone=* beschränkt, aber das könnte natürlich noch erweitert werden…
Es werden alle Telefonnummern, die in einem falschen Format sind, angezeigt. Dabei ist es total egal, wo die Nummern als Tag eingetragen sind.
Das ist mir beim Testen auch schon aufgefallen… So was in der Richtung wird auf jeden Fall hinzugefügt!
Ja, das ist mir bewusst. Die Challenge bei Maproulette sucht nach phone=, contact:phone=, fax=* sowie contact:fax=* mit Werten, die falsch formatiert sind. Mein Tool hingegen sucht im Moment nur nach phone=*…
Was meinst du mit es bekommt die Änderungen an Maproulette vorbei nicht mit? Hat dich Maproulette auf einen fehlerhaften Eintrag hingewiesen, den du vorher mit meinem Tool berichtigt hast? Wenn ja, liegt das daran, dass Maproulette die Suche nach fehlerhaften Werten nur dann startet, wenn der Inhaber der Challenge das möchte… Dass mein Tool dich auf einen Eintrag, den du mit Maproulette gelöst hast verwiesen hat, kann eigentlich nicht sein… Mein Tool fragt jedes Mal, wenn der Nutzer den Task neulädt, die neuesten Daten ab. Die einzige Möglichkeit, wie ich mir dass erklären kann, ist, dass die Nummer nach wie vor falsch formatiert ist…
… kleiner Nachtrag noch …
neben den phone Einträgen, die am ways kleben und nicht mit +49 beginnen, wäre es auch noch gut unkorrekt formatierte Einträge zu finden (die fangen zwar richtig an, haben aber dann teilweise ein “-” irgendwo oder sehen so aus: +49(0)2166-146xxx)
Ich habe endlich den Fehler gefunden… Jetzt werden auch Ways und nicht nur Nodes angezeigt. Die Overpass-Query war etwas falsch… Dann hast du wohl doch noch was zu tun
Super, danke … ganz so viel isses gar nicht mehr, in der Zwischenzeit hatte ich schon die Methode der Selektion für mich verfeinert und die Overpass Abfrage in JOSM für diesen Zweck entdeckt.
Allerdings habe ich den Eindruck, daß mit der neuen Version nun die Funktion “Copy new number to clipboard and open editor” anders reagiert als vorher?
Jetzt muss ich immer in iD das zu ändernde Objekt (markiert isses) noch mal anklicken, bevor die Felder zum Editieren erscheinen.
Ich meine das war vorher nicht notwendig ?!?
Wenn du die falschen Einträge via Overpass ermilltelst … könnte man das nicht mit:
node"phone"~“-”;
way"phone"~“-”;
relation"phone"~“-”;
So… Und wieder ist das Tool ein klein wenig besser!
Die Overpass Query habe ich jetzt auf deinen Vorschlag hin verbessert, sodass noch mehr fehlerhafte Einträge gefunden werden können. Danke dafür! Außerdem sollte jetzt auch der Fehler mit dem Öffnen des Editors behoben sein (Das zu bearbeitende Objekt wird jetzt wieder direkt ausgewählt)
Das ist mir auch gerade eben aufgefallen. Mist… Das kann ich mir jetzt aber auch nicht mehr erklären… Ich benutze für die Nodes und die Ways genau den selben Code… Das muss dann ein Fehler von iD sein. Ich glaube viel mehr kann ich da leider nicht machen… Tut mir leid…