Tool zum "Internationalisieren" von Telefonnummern

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?

–ks

Welchen der über tausend Changesets meinst du? :wink:

Zu meiner Verteidigung:
Es sind auf jeden Fall nicht 6000 Einträge, weil ich bestimmte Tags wie

contact:phone

oder

fax

sowie

contact:fax

kaum oder überhaupt nicht verwendet habe…

Noch ein Problem gefunden: http://www.openstreetmap.org/node/294002721/history

phone wurde hier gar nicht umgesetzt, jetzt gibt’s da ein:

phone = 0492193030
und
contact:phone +49 4921 93030

Wahrscheinlich hat das 049 vs. +49 zu Problemen geführt.

http://www.openstreetmap.org/node/623872423/history
hier war die Nummer vorher Mist, ist jetzt immer noch Mist:

vorher: 05531-
jetzt: +49 5531

http://www.openstreetmap.org/node/2621306492/history

Restaurant in Hamburg, war vorher schon Murks, wurde jetzt überarbeitet und ist immer noch in Rumänien (+40).
vorher: + 40 42937788
jetzt: +40 42937788

http://www.openstreetmap.org/node/2000071424/history
SGVN Marina Hamburg

War vorher auch schon Murks, Nummer nun schön formatiert, aber immer noch in Russland :roll_eyes:
Sollte lt http://www.toernplaner.net/index.php?module=4&id=5082 aber ein +49 700 … sein.

http://www.openstreetmap.org/node/2825116497/history
Nummer komplett zerhackt:

vorher: phone = 0421 16 100 717 - 0176 62 79 44 52

jetzt: phone = +49 421 161007174452

WTF???

Weiter geht’s:
http://www.openstreetmap.org/node/2973260919/history

vorher: phone = 04131 37861 37496
jetzt. phone = +49 4131 3786137496

gemeint waren aber zwei unterschiedliche Nummern: +49 4131 37861 und +49 4131 37496
wie man leicht auf der Webseite nachlesen kann.

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…)?

Sorry, aber wenn du erst schreibst:

und dann

… dann geht mein Logikmodul von fast 6000 geänderten Einträgen aus.

–ks

Gibt es eine Methode, die sicherstellt, alle Fehler zu erwischen? Bislang scheinen es mir Zufallsfunde zu sein.

Wenn nicht, sollten wir reverten. Sicher hat jemand (der den Samstagabend wohl lieber mit was anderem verbracht hätte) ein nettes Skript dafür.

–ks

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…

Fazit: für mich funktioniert das Ganze nur vollständig manuell. Ich sehe da an ein vergleichbares Tool zu https://osm-suspects.gbconsite.de/#11/51.9026/13.9894/osm-wrongcity-wrongstreet-outsideplz als gangbaren Weg. Das sollte aber eben Nur die potentiellen Fehler aufzeigen, Links zu Editoren bieten und die Möglichkeiten bieten, FalschPositive zu markieren.

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.

Sven

Hallo,

laut Wiki sollte übrigens noch ein Leerzeichen nach den ersten drei Nummern (nach der Vorwahl) eingefügt werden: https://wiki.openstreetmap.org/wiki/DE:Key:contact

Gruß
Mecki

Da war doch mal was:

https://forum.openstreetmap.org/viewtopic.php?id=60382

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 :slight_smile:

Hi,

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…

Hi,

“Nur” gestern kann ja eigentlich nicht sein.
Dieses Changeset von Freitag: https://www.openstreetmap.org/api/0.6/changeset/54470613
hat dan gleichen Inhalt beim created_by wie das von gestern: https://www.openstreetmap.org/api/0.6/changeset/54479381

Du solltest das aber eigentlich besser wissen als ich :slight_smile:

Viele Grüße
Pascal

So… das Skript läuft momentan und alle Änderungen werden zurückgesetzt!

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 :wink:

  • 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 :sunglasses: