Pflege der deutschen PLZ-Daten in OSM

Ist mir nicht entgangen, danke für’s Aufräumen!

65 weniger, von 56171 Weitersdorf nach 56190 Bendorf verschoben

Bernd

Ps: danke für den Service

06792/06794 Sandersdorf-Brehna (268 Fälle) gefixt. PLZ-Grenzen falsch.

Kümmere mich gerade um Neuss

41464/41460 Neuss (477 Fälle) korrigiert.

Grenzverlauf zwischen 56179 Vallendar und 56191 Weitersburg passte auch nicht, korrigiert.

Für den Kreis Neuwied habe ich fast alles korrigiert, werde die Auswertung abwarten

@Wambacher: Ist es mit vertretbarem Aufwand möglich, die Irrläufer separat anzuzeigen, die seit der letzten Auswertung dazugekommen sind?

Baßtölpel

Anmerkung: Etliche “neue” Irrläufer sind keine neuen Fehler, sondern waren verborgen vorher schon da. Sie werden nur durch inzwischen genaueres Grenzmapping (Straßenseiten) jetzt sichtbar. Ansteigende Irrläuferzahlen müssen kein Indiz für schlechtere Qualität der Grenzen sein.

Auch wenn es mir um die Fälle ging, in denen die Zahl der Irrläufer gestiegen ist (bisher Berlin, RLP), wäre so eine Auswertung auch hilfreich, um die verborgenen Fehler schneller aufzuspüren, damit man das frisch bearbeitete Gebiet endgültig abhaken kann. Tendenziell wird so eine Auswertung aber mit der abnehmenden Zahl alter Fehler unwichtiger, deswegen auch meine Einschränkung “mit vertretbarem Aufwand”.

Baßtölpel

nein. Ich zähle nur den aktuellen Stand und habe keine Informationen über die gezählten Einzelobjekte, geschweige davon auch noch eine History.

Gruss
walter

Hab wieder eine Runde in Sachsen Anhalt gemacht, neue Liste wäre gut :smiley:

Heute Nacht sind Hamburg, Berlin, Hessen und Brandenburg durchgelaufen, Sachsen-Anhalt läuft.

Gruss
walter

Bremen sollte jetzt sauber sein.

Warum werden addr:postcode=* und addr:contry=* von den “Adressen” entfernt?

Ich finde das nicht richtig!

Das wird in der Tat kontrovers diskutiert. Ich bin persönlich dafür, addr:country zu löschen und addr:postcode nur mit Bedacht einzusetzen.
Derzeit lösche ich die addr:postcode nicht (und habe ich auch nie, wenn es richtig war). Es ist sicherlich richtig, dass hier nicht verfrüht Fakten geschaffen werden sollten.

Was spricht aus Deiner Sicht für addr:country?

hier wurde gelöscht

Es geht darum die (komplette) Adresse an den POI’s nutzen zu können.

In dem Beispiel war der postcode falsch (01075). Wie gesagt, derzeit würde ich das korrigieren und habs jetzt wieder drangepappt.

EDIT: Es soll niemand unglücklich werden, weil seine Tags (sofern richtig) entfernt wurden. Ich selbst werde in der Regel nur Hausnummer und Straße taggen.

Der Staat sollte in D in der Regel aus dem Zusammenhang klar sein.
Ausnahme ist für mich der grenznahe Bereich. Da gibt es z.B. zwischen Schaffhausen und Bodensee Gebiete, wo man vor lauter Enklaven, Exklaven und Grenzschlenkern in hohen Zoomleveln nicht weiß, auf welcher Seite der Grenze man gerade ist.

Nahmd,

Wenn ich mit meiner tollen Datenbank die Einträge nimmer brauche, so braucht auch kein anderer die mehr. Ist doch leicht zu verstehen?

Gruß Wolf

PS: Der Psychologe nennt das “mangelnde Fähigkeit zur Perspektivenübernahme”. Wie ich es nenne, ist nicht veröffentlichungsfähig.

Es geht auch darum dem “Nutzer” eine leichte Möglichkeit zur Verfügung zu stellen. Wenn das aber nur über zig-Abfragen (und Code-Schnipsel) funktioniert, wird er weiter bei g… seine Einträge machen.

Das Prinzip sollte doch sein: Einfach → und dann weiter (nach speziellen Bedürfnissen).

Wir sagen immer: zu OSM kann jeder beitragen und es nutzen - dann sollten wir auch den* “einfachen Nutzer” eine “einfache Möglichkeit” lassen*.

Gerade OpenLinkMap bot gleich einen praktischen HTLM-Code zur kleinen Karte an. Und auch die flosm-Idee finde ich als “einfacher Nutzer” gut.

Das ist jetzt zwar fast schon ein neuer Thread, aber an den PLZ-Daten sieht man die Problematik recht gut:

Gegen Redundanzen spricht, dass sich die Einträge widersprechen können (in welchem Ausmaß, kann man an der Irrläuferliste von wambacher sehen). Wären die PLZ nur an den Grenzrelationen, könnte das nicht passieren (one information at one place).

Für Redundanzen spricht, dass auch die Grenzrelationen oft ungenau sind. Ohne (dann nicht redundanten) Eintrag an Gebäuden oder POIs wäre das längst nicht so einfach zu entdecken.

Generell plädiere ich dafür, vorhandene Attribute bis auf Trivialitäten wie layer=0 oder oneway=no nicht zu löschen, auch nicht Beinahe-Trivialitäten wie address:country. Ich trage letzteres aber bis auf Ausnahmen auch nicht ein.
Redundante Information kann eben auch Abfragen deutlich einfacher machen.