Ich habe eine Liste mit PLZ von einem Kunden bekommen, der unseren auf OSM basierenden Geokoder nutzt. Wir haben diese Liste mit den OSM-Daten verglichen und folgendes Ergebnis bekommen:
2 PLZ aus seiner Liste waren in OSM nicht vorhanden
10 PLZ (verifiziert über die Internetseite der DPAG) fehlten in der Liste des Kunden.
Damit haben die OSM-PLZ-Daten 10:2 gegen einen kommerziellen Datenanbieter gewonnen.
Die tatsächliche Anzahl der PLZ in D kenne ich leider auch nicht, wir haben aber nichts gefunden, was in OSM falsch (veraltet) vorhanden ist.
04862 Fehlte auch lange in OSM (bis vor 2 Monaten). War bei Arnulf 2010 nicht drin. Tauchte in den DPAG-Änderungslisten auch nicht auf. Komisch.
06711 Kam bereits 2010 dazu
06868 Kam bereits 2009 dazu
08344 Gibt es mind. seit 2010, war immer in OSM
24222 Kam bereits 2008 (!) dazu
24976 dito
98630 seit 2012
99090 dito
99095 dito
99820 bereits seit 2010
Wir lernen also: Einmal PLZ-Daten kaufen reicht nicht! Das gilt auch für die Händler von PLZ-Daten und -Websites.
Wie soll das den gehen? Normalerweise ist meine PLZ-Karte relativ aktuell (Lag von 60 Sekunden bis leider einige Stunden).
Oder meinst du meine WIKI-Karte? Das ist ja wirklich ein statisches Bild.
Ansonsten würden mich die beiden PLZ interessieren, die euer Kunde nicht in OSM gefunden hat. Komisch, daß Gehrke die nicht wissen wollte.
Aber die Anzahl 8203 besorgt mich. Die von Detlev vorgelegten Daten geben nur begrenzt Auskunft über veraltete PLZ, die noch in OSM schlummern könnten.
Da ist schon was dran, daher lass ich die ja auch nach und nach durchlaufen - nur nicht ganz so oft wie früher, da die Pflege der Wiki-Datei ein wenig lästig ist. Irgendwie müsste man das automatisieren können.
Gruss
walter
hab mal berlin, sachsen anhalt und sh auf die reise geschickt. Timestamp der DB 15:02Z
Danke für die Auswertung auch von Hessen - da habe ich ja schon etwa die Hälfte geschafft.
@wambacher: Eins wundert aber trotzdem: Wenn ich mir die ersten 8 Fehlerzeilen (also den ganzen ersten Absatz) der neuen Fehlerliste_Hessen ansehe, habe ich diese am 25.4. zwischen 19:00Z und etwa 20:00Z behoben (Neue PLZ-Grenzen in der letzten Zeile, alles darüber waren Korrekturen von PLZ-Einträgen). Warum sind dann diese Änderungen in Deiner Auswertung mit “timestamp=2014-04-26T03:34:02Z” noch nicht enthalten?
Lange Version: Heute Nacht war ein heftiges Gewitter in unserer Ecke und ich hab die Kiste ca 2 Minuten vor dem dann tatsächlich erfolgten Stromausfall runtergefahren. Und dann hab ich mich wohl bei dem State-File zum Neustart vertan.
Muss den Import wohl um ca 24 Stunden zurücksetzen und dann alle Auswertungen erneut starten - das Wochenende ist gerettet
Gruss
walter
Nachtrag: Da ich beim Update-Prozess inzwischen jeden Pups Schritt logge, hab ich den Mist jetzt ganz genau gesehen:
Dein Edit 21:04Z (23:04 MEZ),
Shutdown 23:51 , gerade aktuelles - aber nicht abgeschlossenes - Diff-File #844526, <— da sind deine Updates drin
Neustart 00:06 mit Diff #844527 - und das war eines zu spät.
Hessen habe ich jetzt fertig. Dabei ist mir aufgefallen, dass einige Knoten/Wege, durch neue PLZ-Grenzen bzw. verschobene Grenzknoten jetzt auf der anderen, (richtigen) Seite der Grenzlinie liegende Adressen vom 25.4. in der Auswertung vom 30.4. noch als Fehler enthalten sind (z.B. w196329842 oder diesen durch Verschieben korrigierten Grenzknoten: n2816659581).
Beim Turm in folgender Zeile ist nich ganz klar, welche PLZ er hat:
60310 Frankfurt am Main (Taunusturm) | {w185439344}
Eine Postfach-Adresse:
34369 Hofgeismar | {n2087556083}
In dieser Zeile haben wir als Orte Hamburg und ein 93 km südlich der Position gelegenes Albersweiler (Jeweils Telekom-(man_made=MDF)). Vermutlich falsche Positionen.
65439 Flörsheim am Main | {n307179603,n307199380}
Dann kann Hessen jetzt wieder eine Auswertung mit Updates ab 14:15Z vertragen.
