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…
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
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
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
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
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
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
Ich würde das Tool sein lassen (sorry, ist für den Programmierer hart, weil es Arbeit gemacht hat)
War nur ne Arbeit von einem Abend… Also nicht allzu viel!
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).
Das ist eigentlich genau dasselbe, was die Challenge von maproulette.org macht (http://maproulette.org/ui/metrics/2692). Insofern werde ich mein Projekt erstmal in die Tonne kloppen
Oder in JOSM einbauen, wenn es der Validator noch nicht kann.