Da schon so schnell zwei Fehler gefunden wurden, wäre ich dafür, den CS komplett zu revertieren und das Tool erstmal mit der Community zur Einsatzreife zu entwickeln.
Wie mmd schon schrob: Das war dann wohl eher ein Alphatest. Wieviele Fehler da wohl in allen 6000 behandelten Einträgen erzeugt wurden?
Restaurant in Hamburg, war vorher schon Murks, wurde jetzt überarbeitet und ist immer noch in Rumänien (+40).
vorher: + 40 42937788
jetzt: +40 42937788
Entschuldigung, wenn die Frage vielleicht etwas blöd ist, aber wie wollen wir jetzt weiter vorgehen?
Sollen wir hier alle gefundenen Fehler sammeln und diese korrigieren oder einfach alles rückgängig machen (wobei ich leider überhaupt gar keine Ahnung habe, wie das gehen soll…)?
In meinen Augen sind Telefonnummern nicht automatisiert/ halbautomatisiert korrigierbar… Das muß zwangsläufig zu Fehler führen… Beispiele siehe oben.
Für mich sind die Randbedingungen zur Fehlerkorrektur eigentlich fast ähnlich wie bei den PLZ…
Aber im Gegensatz zu den Vorwahlen in D haben wir aber bei den PLZ Grenzen als Anhaltspunkte…
Diese fehlenden Vorwahlgrenzen machen die Sache noch weitaus schwieriger… Ich bezweifle aber mittlerweile auch, daß sich solche “Vorwahlgrenzen” einigermaßen effizient erstellen lassen.
Wie bei den PLZ kann man sich aber auch bei bei den Vorwahlen nicht darauf verlassen, daß alle Nummern in einem Gebiet stets die selbe Vorwahl haben… (Stichtwort Grenzproblematik: wrnn Orte auf Grenzen unterschiedlicher PLZ’s oder wie hier Vorwahlen liegen).
Zur der ganzen Sache kommt hinzu, daß die Schreibweise der Telefonnummern noch differenzierter ist, als man es bei den PLZ’s jemals haben wird…
Jegliche automatisierte/ halbautomatisierte Korrekturen lehne ich kategorisch ab… und bin erst mal grundsätzlich für einen Revert.
Findige Programmierer sollten aber entsprechende permantente Tools präsentieren, die die Fehler anzeigen, so daß der User diese nach eigenem Ermessen korrigieren kann. Das schließt auch eine mögliche Fehlerprüfroutine in JOSM mit ein.
Nach kurzer Recherche habe ich auch keine Anforderung in den Standards gefunden. Wenn es keine Einwände gibt, sollte das also wirklich entfernt werden.
So… ich hab mich jetzt dafür entschieden alles rückgängig zu machen!
Ich komme auf insgesamt 1291 Changesets die ich gestern erstellt habe. Falls irgendwas nicht klappen sollte, halte ich euch natürlich auf dem Laufenden
habe mal kurz in meine DB geschaut:
In den letzten 4 Tagen hast du 1387 Changesets erstellt.
Davon haben 1342 Changesets das Wort “Phone” im Kommentar.
Davon haben widerum “nur” 1182 Changesets auch wirklich mind. eine Änderung.
Dies dürfte die Anzahl sein, die revertet werden muss.
Viel Erfolg.
Viele Grüße
Pascal
PS: Habe auch mehrfache Änderungen von dir an einzelnen Nodes gesehen.
Ich habe das Programm auf jeden Fall nur gestern (ca. zwischen 9 und 17 Uhr) ausgeführt. Die anderen Changesets müssen dann Challenges von maproulette sein…
Ich muss zugeben, dass ich aus Datensicht so ein Tool auch schreiben würde. Allerdings muss man hier wieder die Frage stellen, welchen Zweck wir mit den OSM-Daten verfolgen. In erster Linie sollte es darum gehen, korrekte Informationen einzupflegen. Das bedeutet nicht, dass sie auch in jedem Falle korrekt formatiert sein müssen. Bei Straßen und dergleichen und selbst bei Adressen ist das sicher erforderlich, weil – und das ist der Knackpunkt – weil diese Daten in erheblichem Maße genutzt werden, z.B. für die Kartendarstellung. Diese Nutzung ist stark automatisiert und bedarf natürlich korrekt formatierter Daten.
Nun zu den Telefonnummern: Man wird zustimmen, dass OSM kein Telefonbuch sein soll. Zumindest derzeit nicht. Insofern vermute ich, dass die vorhandenen Telefonnummern letztlich vor allem visuell von Menschen genutzt wird, selbst dann, wenn automatisierte Tools sie irgendwo hin transferieren (auf Flyer, in Karten-Legenden, …). In diesem Lichte ist der Zweck erfüllt, wenn der Nutzer die Telefonnummer aus dem Kontext heraus korrekt ermitteln kann. Jedes der obigen Beispiele wäre damit “brauchbar”, weil selbst Fehler beim Lesen erkannt und korrigiert würden.
Schlussfolgerung für mich persönlich: Ich würde das Tool sein lassen (sorry, ist für den Programmierer hart, weil es Arbeit gemacht hat) und die Korrekturen “sich selbst überlassen”, sprich, es Anwendern überlassen, die ein Problem mit den Fehlern haben. Zu diesem Zweck kann man das Tool aber vielleicht in einer Form bereitstellen, die es erlaubt, in einem gezielten Bereich oder nach Filtern Nummern zu korrigieren (z.B. im aktuellen Kartenausschnitt in JOSM oderso).
Besser wäre es natürlich, gleich bei der (Neu-)Eingabe anzusetzen.*
Mag einerseits ein Generationenproblem sein, andererseits vielleicht auch ein bisschen fehlendes technisches (Programmierer-)Wissen und sich dessen einfach gar nicht bewusst sind, warum man das internationale Format verwenden sollte … ich kenne leider genug Menschen, die typisch deutsch die Telefonnummern mit 0… ins Smartphone eintragen, und sich dann im Ausland wundern, warum die Telefonnummer nicht mehr geht … aber hey, vielleicht warten wir einfach noch eine Generation ab, dann sollte sich das mit der Telefonnummer ganz und gar erledigt haben
Im Web und den meisten Formularen gibt es ja häufig schon die Trennung zwischen Landesvorwahl (mit DropDownBox), Vorwahl und Rufnummer
Wer einen passenden Editor benutzt, der die getrennte Eingabe der Elemente unterstützt bzw. das Ergebnis überprüft, ist ja auf der sicheren Seite. Keine Ahnung, ob JOSM und iD da was haben. Aber das Tool zielte vermutlich vor allem auf eine Bereinigung des Bestands ab.
Das war mir schon klar. Ich wollte aber nochmal verdeutlichen, dass es immer besser ist die Eingabe zu verbessern, als vermurkste Daten nachträglich zu “bereinigen”.
Letztendlich ist aus Programmierersicht OSM mit seiner Freiheit alles wie auch immer zu Erfassen ja eigentlich fast schon sowas wie ein Supergau