ich meinte aber dein “mit einem Punkt für jeden Irrläufer” - die hab ich nicht mehr.
#Fehler pro PLZ-Gebiet und Summe pro Bundesland kommen ja neuerdings mit rüber.
Mit der Aggregation der Irrläufer sieht man gut, dass Frankfurt am Main ziemlich stark betroffen ist.
Allein 829 Fälle für 60489 vs. 65936 Frankfurt am Main.
hab von ca 10 Minuten gerade Hessen erneuert, die Werte haben sich aber nicht viel geändert. Ich werde morgen wohl mal eine Auszeit vom Programmieren machen und in Hessen ein wenig putzen.
Gruss
walter
ps: Berlin rennt und Brandenburg wird heute wohl auch noch fertig.
Habe ja immer einen Blick auf die Tabelle. Das waren schon Deine aktuellen Zahlen. Wollte mir auch gerade Ffm anschauen, aber dann warte ich da mal ab.
Hab mir den schlimmsten Fall doch angeschaut und auch gefixt. 829 falsche addr:postcode auf einem HAufen. hatte in Bayern auch schon ein Dorf mit über 1000 falschen. Soviel zum Argument “besser addr:postcode als boundary=postal_code”.
Nur keine Hemmungen, heute passiert eh nix mehr bei mir. Muß noch nen Popup zum Laufen kriegen.
Gruss
walter
Was ist da in Berlin los? Es wird schlimmer! Ein user hatte z.B. seltsame Änderungen gemacht und großflächig Häuser mit falscher PLZ und Straße annotiert (“Scharfenberger Straße 8 A; 13505 Berlin”).
EDIT: Hab eine PN geschrieben. User schafft mit JOSM.
Frag ihn doch mal.
ps: Bitte niemanden an den Pranger stellen. wer’s wissen will, findet es eh raus.
Hab das falsche “addr:”-Tagging jetzt an ca. 420 Häusern im PLZ-Gebiet 13629 komplett entfernt. (Aber das war wohl nicht alles) Glücklicherweise waren meist die Eingänge separat mit richtiger Adresse getaggt.
wollte gerade etwas im ffm machen und habe festgestellt, daß du einfach die falsche PLZ rausschmeisst anstelle sie zu korrigieren.
Mir ist klar, daß das langfristig wohl ok ist, aber das derzeitige Löschen ist eigentlich noch nicht “abgesegnet”. Zumindest gibt es Stimmen hier im Forum, die für ein Belassen sind.
walter
Gut. Ich dachte, besser weg als falsch (und es ist seeeehr oft falsch). Ich sehe im Wiki auch keine Zwangsläufigkeit für addr:postcode (ebenso nicht für addr:country, addr:city).
Meine Meinung ist ja, man sollte addr:postcode eher feindosiert einsetzen, wo es hilft Fehler zu finden. Das mache ich auch und füge das Tag selbst dort hinzu, wo es das bisher nicht gab.
Wenn das Löschen so kontrovers ist, werde ich darauf verzichten. Die Fehlerbehebung wird dadurch natürlich nicht flotter.
Der User hat mir geschrieben, dass er seinen Fehler jetzt vollständig korrigiert habe.
Die ersten 448 “Irrläufer” in Brandenburg sind korrigiert (alle noch mit addr:postcode).
Ich mache es eigentlich auch so, dass ich es genauso bei Veränderungen lösche wie z.B. access=yes vehicle=yes motor_vehicle=yes motorcar=yes car=yes bicycle=yes foot=yes an highway=residential, sofern es mit den Grenzrelationen übereinstimmt oder falsch ist und nicht direkt an Grenzen liegt (also nahezu immer).
“reden” wir heute noch ein wenig drüber und entscheiden heute Abend?
Ich bin eigentlich auch für moderates Löschen, will aber nicht die Anwender verärgern, die keine Spatialen Abfragen machen können, sondern mit partiellen Extrakten arbeiten (müssen).
Arbeitstechnisch ist es doch das Gleiche (in Josm): Tags ändern oder Tags löschen - was macht mehr Mühe?
Ok, “richtige” PLZ eintragen dauert etwa 2 Sekunden länger 
Gruss
walter
Ok. Mein Verständnisproblem: Um welche Art von Anwendung/Anwender geht es dabei? Welches Device, welche Software, welcher Usecase?
Für die meisten Adressen ist addr:postcode ja schon bisher eh nicht eingetragen. addr:country|city wohl noch seltener (müsste ich mal auswerten).
Beim Korrigieren der Irrläufer bitte immer die PLZ für die betroffene Adresse/Straße prüfen.
Habe gerade ein paar Fälle gesehen, bei den die Grenze gemäß addr:postcode geändert wurde, obwohl die Tags selbst (mal wieder) falsch waren.
Zur Erinnerung: Wir dürfen die Korrektheit einer Adresse bei der DPAG prüfen.
Um es etwas deutlicher zu sagen: Bei den paar Fällen die ich so nebenbei mitbekommen habe (z.B. via OSM-Notes; mir sind Postleitzahlen eigentlich egal) waren immer die Tags falsch und die Grenzen richtig…
Für die Anwendungen, die damit nicht umgehen können [1] könnte ja jemand™ ein einfaches Tool zum Vorbereiten der Daten schreiben
[1]: Usecase: direkte Nutzung von kleinen .osm-Extrakten; Software: (fast?) alle ohne Datenbank; Device: potentiell alle. Wir haben zu wenig Tools, die OSM-Daten in benutzbarere Datenformate konvertieren und zu viele, die OSM-Daten direkt nutzen.
@wambacher: Wohin sollte dein Link zeigen?
Stimme Dir zu.
Zum Usecase meine ich das etwas konkreter, z.B.: “User nutzt OsmAnd (oder sonst was) auf dem Handy, um die Postleitzahl eines Gebäudes nachzuschlagen, weil er dem Bewohner einen Brief schicken will.”
Wie wahrscheinlich ist dieser Usecase? Nach meiner Einschätzung nahe 0. Dann eher “User öffnet Google Maps (leider), um PLZ nachzuschlagen” oder “User öffnet spezielle App (mit OSM-Datenbasis), um PLZ nachzuschlagen”.