OpenStreetMap Forum

Sehr interessant, habe mir das gerade mal angeschaut. Würde man, wie oben von mir vorgeschlagen, zusätzlich das Vorhandensein eines addr:street-Tags fordern, blieben die "Hausnamen" des UKB außen vor. (Jene in Berlin-Siemensstadt ebenfalls.)

Die beiden Hausnummern an der Hautklinik (12 und 325, jeweils Sigmund-Freud-Straße) sind aber nicht so gewollt, oder?

Wie oben geschrieben, glaube ich nicht, daß sich dieser Fehlertyp mit der notwendigen Sicherheit automatisch beheben läßt. Schon alleine die verschiedenen Tastaturlayouts erschweren die Sache erheblich; dazu kommt, daß etwa "/" durchaus korrekt und "&" zumindest mit Absicht verwendet werden kann. Selbst für eine Heuristik, die nur einen Teil der Fälle sicher korrigieren kann, scheint mir der Programmieraufwand in keinem angemessenen Verhältnis zu den vorhandenen Fehlern zu stehen. Aber ich bin gespannt, was Du Dir da ausgedacht hast - vielleicht liege ich mit meiner Einschätzung ja auch falsch. Allerdings habe ich heute (zumindest in DE) das Testmaterial drastisch dezimiert.

PS. Selbst wenn aus Deinem Korrekturskript nichts werden sollte - Du hast Dir ja sicher einige Gedanken zur Filterung problematischer Hausnummern gemacht, die könnten evtl. im housenumbervalidator Verwendung finden. Ich habe auf die Schnelle nur nach einer kleinen Auswahl verdächtiger Zeichen gesucht:

static const regex housenumber_strangechars ("[\"#!*$%&=^]")

Mit einiger Verspätung nun noch einmal zu den "geshifteten" Hausnummern (also ! statt 1 etc.).
Ich habe nun den Bestand nach entsprechenden Hausnummern durchsucht. Es gibt durchaus reichlich Hausnummern wie "!" oder "&"; aber eine automatische Korrektur ist - zumindest mit vertretbarem Aufwand - nicht sinnvoll möglich. Bei "!" mag es noch gehen, aber schon bei "&" gibt es Probleme: Je nach Tastaturlayout liegt "&" entweder auf der 6- oder der 7-Taste. Da hilft nur: nachsehen, auf welcher Straßenseite und zwischen welchen anderen Nummern die fragliche Hausnummer liegt. Auch "1#" kann auf "13" (QWERTY-Layout) zurückgehen oder (m.E. häufiger) auf einen Wurstfinger auf der Returntaste (QWERTZ, insbesondere Notebooktastaturen).

Daneben gibt es noch Fälle, wo die Hausnummer zwischen Anführungszeichen steht (die meisten davon in Hannover und von ein und demselben Mapper), oder ganz eigenartige Dinge wie f/*r, aber auch legitime Exoten.

Ich werde mich demnächst mal daran machen, einige der manuell korrigierbaren Sonderzeichen zurechtzurücken. Sobald ich dem Filterprogramm ausgetrieben habe, reichlich falsch positive Resultate mit u.a. ½ zu liefern, kann ich das Suchergebnis auch bereitstellen, falls jemand mithelfen will. Edit: Lohnt nicht, zu wenige.

Nichts wird so heiß gegessen, wie es in der MOTD steht
http://josm.openstreetmap.de/ticket/8465

Die Frage erinnert mich an http://forum.openstreetmap.org/viewtopic.php?id=20610 .
Eine fertige Anwendung gibt es wohl nicht, aber die im verlinkten Faden gegebenen Hinweise zum Selbermachen sollten auch hier Anwendung finden.

Die Frage nach der Legalität ist inzwischen hinlänglich beantwortet, aber in der Praxis tut man sich mit dem Fotografieren häufig keinen Gefallen, wie auch Deine eigene Schilderung belegt. Ich habe vor längerer Zeit mal in einem Stadtteil die Hausnummern per Foto statt Papier und Stift erfaßt, um den möglichen Zeitvorteil zu ermitteln. Unter Berücksichtigung diverser mehr oder weniger angenehmer Gespräche mit Anwohnern und einer von diesen herbeigerufenen Zivilstreife war dieder Vorteil klar negativ. Übrigens gibt es Leute, die tatsächlich glauben, Google Street View ("da haben wir schon widersprochen") nehme seine Bilder zu Fuß mit einer fünf Jahre alten Kompaktkamera auf.
(Traurige) Konsequenz aus solchen Begegnungen: beim Mapping möglichst wenig auffallen, das steigert den Durchsatz beträchtlich. Selbst wenn man per Fahrrad etwa Hausnummern mappt, sollte man darauf achten, den allfälligen Notizstopp nicht versehentlich in der Nähe eines Haufens zur Abholung bereitgelegter Gelber Säcke einzulegen. (Den Hintergrund, warum die Dame in Sorge um ihre Verpackungsabfälle zur Tür herausgestoben kam, kenne ich freilich bis heute nicht.)

Dazu hat Frederik in der Github-Diskussion aber einen ganz wichtigen Punkt aufgezeigt: Solange iD nicht eine gewisse Nutzerbasis unter den regelmäßigen, erfahrenen Mappern erreicht hat, sollte man Anfängern nicht standardmäßig diesen Editor hinwerfen. Wenn sie dann nämlich eine Frage haben und auf help.~ oder Foren und Mailinglisten regelmäßig nur ratloses Schulterzucken oder die Antwort "nimm Potlatch (oder gleich JOSM)" ernten, ist auch nichts verdient.

Die Idee gefällt mir, wenngleich ich auch bei dieser Variante noch eine Wartezeit von einigen Wochen befürworten würde. Die Bewertung, mit welchem Editor mehr Fehler entstehen, ist aber schwierig. Jegliche (automatische oder - sehr aufwendige - manuelle) Auswertung erfaßt nur immer bestimmte Klassen von Fehlern und hat damit einen Bias. Hingegen läßt sich sehr einfach objektiv erfassen, welcher Anteil einer bestimmten Nutzergruppe nach z.B. am Tag N oder innerhalb von N Tagen nach dem ersten Edit einen weiteren vornimmt oder an N der folgenden M Tage mindestens einen weiteren Änderungssatz aufmacht, oder sogar den Umfang der Änderungssätze einbeziehen. Ich hatte vor längerer Zeit mal mit sowas rumgespielt, siehe hier (mit Daten von 2011). Bisher bin ich noch nicht dazu gekommen, dies weiter zu verfolgen.

JOSM tut genau dies: wenn ein Objekt, das ich löschen will, Teil einer Relation ist, kommt eine Nachfrage. Allerdings lösche ich nicht so häufig Objekte, daß ich diesen Hinweis als störend empfände. Wenn er auftritt, bietet er mir die Gelegenheit zu prüfen, ob meine Bearbeitung möglicherweise eine größere Tragweite hat als beabsichtigt.

Wenn man sich mal im MP-Layer von OSMI umschaut und speziell den kaputten PLZ-Grenzen nachgeht, trifft man häufig auf (Potlatch-)Änderungssätze mit Kommentaren wie "delete unexisting way" (originalgetreues gebrochenes Englisch). Da war dem betreffenden User ganz offensichtlich nicht klar, daß der vermeintlich unnütze, "nicht existente" Weg vermöge seiner Relationsmitgliedschaft doch einen Sinn hat (und nicht etwa eine in der Realität tatsächlich nicht vorhandene Straße durch die Pampa darstellt). Ein Hinweis à la "hinter diesem Weg steckt mehr als du siehst" hätte die Löschung womöglich verhindert - gerade bei einem Editor wie iD, der Relationen komplett vor dem Benutzer versteckt (und lediglich Multipolygone gemeinsam mit einfachen geschlossenen Wegen als eigenen Typ "Fläche" repräsentiert). Allerdings ist man mit dem Wunsch nach solchen Warnungen bei dem Entwickler von Potlatch an der falschen Adresse, und bei den iD-Entwicklern wohl leider auch (vgl. Issue "not every playground has a name").

Huh? Ich habe das gerade mal ausprobiert. iD zeigt die gesamte MP-Fläche als "Weide" an. (Erfordert freilich ein paar Minuten Geduld.)

Abgesehen davon taggen wir nicht für Renderer, QS-Werkzeuge - und auch nicht für unausgereifte Editoren.

Unabhängig von der durch fx99 bereits abschließend beantworteten Frage sei darauf hingewiesen, daß das massenhafte Herunterladen von Kacheln unerwünscht bzw. durch die Tile Usage Policy ausdrücklich untersagt ist.

http://download.geofabrik.de/north-america.html

Das müßte durch Erhöhen der Einstellung search.history-size in den "Erweiterten Einstellungen" gehen.