Die Zahl ist schon am 04.01. deutlich zurückgegangen (−256). Der xybot korrigiert jetzt übrigens auch addr:postcode-Werte der Form “D-12345” und “DE 12345”.
Es ist jetzt eine Version für ganz Deutschland verfügbar: http://gulp21.bplaced.net/osm/housenumbervalidator/
Bitte beachten, dass max. 1800 Probleme auf einmal angezeigt werden (wenn nötig, reinzoomen).
Durch die Umstellung auf die Datenbank gibt es jetzt leider wieder ein Encoding-Problem. An der Datenbank selbst kann es eigentlich nicht liegen, da in der Ausgabe die Umlaute in Ordnung sind. Ich vermute, dass ich OpenLayers noch irgendwie den Codec mitteilen muss. Es wäre schön, wenn mir jemand sagen könnte, wie ich das Problem lösen kann.
Vielen Dank, konnte gleich ein paar Fehler ausbessern, die mir vor einiger Zeit unterlaufen waren.
Tolle Sache, “meine” Daten sind sauber 
kann also getrost weiter ODBL-remappen 
Jetzt werden auch Probleme in Österreich angezeigt: http://gulp21.bplaced.net/osm/housenumbervalidator/?zoom=9&lat=6079441.998&lon=1679165.62212&layers=BTTTT
Und mit dem OSMAddressCorrector gibt jetzt noch ein weiteres Tool zum Aufspüren fehlerhafter Hausnummern.
Es gibt eine größere Zahl false positives, wo eine Präposition im Straßennamen steht, und die klein geschrieben ist. Zum Beispiel von-Links-Straße, an der Mauer. Der Name kann dann tatsächlich so korrekt sein. Ist es möglich, das abzufangen?
Baßtölpel
Ich kann natürlich sämtliche Straßennamen, die mit van|von|an|am beginnen ignorieren lassen. Ich war mir nur mangels solcher Straßennamen in meiner Umgebung nie richtig sicher, ob die Straßennamen auch auf den Straßenschildern mit kleinem Anfangsbuchstaben geschrieben werden.
Dort, wo es mir aufgefallen ist, hatte die die zugehörige Straße die gleiche Schreibweise.
Was wird bei den Straßennamen denn überhaupt getestet?
Baßtölpel
Ein Straßenname wird als problematisch angesehen, wenn eine der folgenden Bedingungen erfüllt ist:
- endet auf “Str” oder “str”
- enthält “Str.” oder “str.”
- erstes Zeichen ist kein Großbuchstabe (Ausnahmen: enthält eine Zahl, auf die ein “e” folgt (z.B. “55er-Straße”), oder (neu) beginnt mit “an”, “am”, “van” oder “von”)
Update 21.02.12: Ab heute werden Straßennamen, die mit einem kleingeschriebenen “an”, “am”, “van” oder “von” beginnen, nicht mehr als “problematisch” eingestuft. (Diese Änderung hat für einen sehr deutlichen Rückgang der Fehlerzahlen gesorgt.)
Zur Vollständigkeit halber sei es auch hier erwähnt:
Es gibt jetzt die Möglichkeit, sich bei einem Art Newsletter anzumelden, bei dem man (fast) täglich eine E-Mail mit einer fehlerhaften Adresse und einem Duplikat bekommt. (Idee von poppei82). Registrierung über “Ein korrigierter Fehler am Tag” unter http://gulp21.bplaced.net/osm/housenumbervalidator/.
In den letzten Tagen habe ich den housenumbervalidator von osmosis auf osmconvert und osmfilter (zum vorfiltern der Dateien) umgestellt. Dank der --all-to-nodes konnte ich den Code des housenumbervalidators vereinfachen (keine Sonderbehandlung der ways mehr), wodurch sich insgesamt eine Laufzeitverkürzung von ca. 75% ergibt.
Sollten sich bei der Umstellung irgendwelche Fehler eingeschlichen haben, bitte melden.
Danke für den housenumbervalidator, das ist ein echt praktisches Tool! Hab gleich mal ein paar Fehler in der Gegend korrigiert und dabei auch einige Häuser bemerkt, die addr:housename statt addr:housenumber verwenden (aber mit einer Nummer als housename). Beispiel: http://www.openstreetmap.org/browse/node/808615479 (hab ich jetzt schon geändert). Das kommt wahrschl. durch die Autovervollständigung im Editor… Vielleicht kannst du sowas als Zusatzprüfung einbauen (also wenn addr:housename eine Hausnummer enthält) und als Warnung anzeigen?
Ach ja, wird die Prüfung eigentlich täglich gemacht?
Danke für die Anregung. Leider ist eine solche Prüfung auf Grund der Programmstruktur nicht so schnell umzusetzen, aber vielleicht baue ich das in Zukunft mal ein.
Die Datenbank wird (meistens) täglich aktualisiert.
Sehr tolles tool, aber ein Feature gibt es das ich mir wünsche: abhaken von verbesserten Fehlern
Das wünsche ich mir auch. 
Ich habe aber momentan keine Idee, wie ich verhindern kann, dass die “Abgehakt”-Information bei einem Datenbank-Update (dabei wird der zunächst der Datenbankinhalt komplett gelöscht) verloren geht.
Das möchte ich noch einmal aufgreifen. Straßennamen mit “von” und “vom” am Anfang nicht als Fehler aufzufassen, halte ich für sinnvoll. Meistens handelt es sich um Straßen, die nach Adligen benannt wurden. Allerdings scheint das auch nicht immer zu klappen, etwa hier (liegt es am Bindestrich?).
Aber klein geschriebene Präpositionen “an” und “am” (sowie “in”, “im”, “auf”, “zur”) am Anfang wären bei den Straßen, die ich kenne, stets falsch. Ich weiß nicht, ob das regional unterschiedlich ist, aber hier beginnen auch Straßennamen mit solchen Präpositionen stets mit Großbuchstaben.
Gerade falsch geschriebene Straßennamen findet man allerdings auch zuverlässig(er) mit dem Adresslayer von OSMI. Wenn die Schreibweise einer Hausnummer vom eingetragenen Straßennamen abweicht (addr:street=“im Eimer”, aber name=“Im Eimer” an einer nahegelegenen Straße), wird “street not found” gemeldet. Insofern muß man den housenumbervalidator in diesem Punkt nicht unbedingt bis ins letzte optimieren. Vielleicht wäre ein Link auf dieselbe Region im OSMI hilfreich. Kombiniert man beide Instrumente, kann man schon einen erheblichen Teil der Fehler erkennen und beseitigen.
Im übrigen denke ich, daß jene Fehler, die xybot automatisch berichtigt, nicht angezeigt werden brauchen, die verschwinden schließlich von selbst. Das wirklich wertvolle Merkmal des housenumbervalidator (was nämlich auch OSMI nicht bietet) ist aus meiner Sicht ohnehin die Erkennung von Duplikaten.
Allerdings hatte ich vor einiger Zeit den Eindruck, daß die Duplikaterkennung nur funktioniert, wenn zwei Adressen in allen Merkmalen übereinstimmen, aber nicht, wenn z.B. :street und :housenumber übereinstimmen, aber eines der beiden Objekte zusätzlich noch :city hat, das andere aber nicht. Hier wäre es m.E. sinnvoll, Abweichungen in :city, :postcode, :country zu ignorieren, wenn beide Objekte höchstens einen bestimmten Abstand voneinander aufweisen. (Bahnhofstraße 1 in 12345 Pusemuckel und Bahnhofstraße 1 ohne Ort und PLZ sind in Ordnung, wenn mindestens $(heuristischer Wert) auseinander.) Daß eine solche Kontrolle mit deutlichem Mehraufwand einhergeht, ist mir klar, aber ich halte sie für sinnvoll.
Na, so schwierig kann das nicht sein. Andererseits sehe ich bei der gegebenen Aktualisierungsfrequenz nicht die Notwendigkeit. Ist ein Fehler erledigt, wird er nach zwei bis drei Tagen auch nicht mehr angezeigt. Bis dahin kann man sich ja einem anderen Stadtteil etc. zuwenden.
Aber wäre es möglich, das Koordinatensystem der Slippymap umzustellen? lat=6446066.23248&lon=890951.76387 im obigen Link ist ja schauderhaft
Sehr gutes Tool.
Sofort in meine Linkliste. 
Als Anregung noch entsprechend zu der Überprüfung der Straßennamen.
Bei Gemeinden mit Ergänzungen im Namen fliegen in den Adressen und den Gemeinde-Nodes auch mehrere Schreibweisen rum.
Mein Beispiel hier ist “Reichenbach an der Fils”, “Reichenbach/Fils”, evtl. noch “Reichenbach a.d. F.” oder alle weiteren Kombinationen mit und ohne Leerzeichen.
Das gleiche gilt natürlich auch für “an der Teck”, “ob der Tauber” usw.
Vielleicht lässt sich’s ja mit reinbasteln. 
Nein, das liegt daran, dass “vom” bisher nicht ignoriert wird.
Es ist wirklich die Frage, ob das überall so ist. Gibt es zufälligerweise ein bundesweit einheitliches Regelwerk für die Schreibweise für Straßennamen? (wahrscheinlich nicht…)
Ist jetzt drin.
Das sind ja hauptsächlich die addr:street=Musterstr. Sachen, deshalb werden Fehler bei addr:street auch in einer anderen Farbe angezeigt. Aber dass die Fehler angezeigt werden, erinnert vielleicht den ein oder anderen wieder daran, dass Abkürzungen vermieden werden sollten.
Ein Hausnummer wird nur denn in die Duplikat-Prüfung mit eingeschlossen, wenn alle addr:*-Werte (ausgenommen country; bei Bremen, Hamburg und Berlin auch ausgenommen city) angegeben sind. Wenn ich mal die Zeit finde, gucke ich mal, ob ich eine Entfernungs-basierte Duplikatsprüfung hinzufüge.
Inzwischen habe ich mir ein paar Gedanken dazu gemacht, und es scheint doch recht einfach zu sein.
Deshalb habe ich mir dazu bisher auch keine Gedanken gemacht.
Erledigt.
Da ist wiederum auch was dran.
Dem sich wundernden Mitleser sollte zu HB, HH, B vielleicht gesagt werden, daß Du das Programm bundeslandweise laufen läßt und zwei Adressen in den jeweiligen Geofabrik-Extrakten der genannten Stadtstaaten - Randbereiche ausgenommen - keine verschiedenen Werte von addr:city haben können
Danke für die Erklärung. Vielleicht steige ich mit dem Hinweis besser durch den Quellcode durch.
Randnotiz: In Deinem Skript “filter” meinst Du übrigens vermutlich power=sub_station (nicht substation).
Danke für den Hinweis.