Hallo Martin,
Am Donnerstag, den 03.10.2013, 14:51 +0200 schrieb Martin Koppenhoefer: > Am 3. Oktober 2013 14:03 schrieb Jörg Frings-Fürst <o...@jff-webhosting.net>: > [...] > > > Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es > > durchaus ein Problem automatisch zu entscheiden welcher Wert richtig > > ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation > > ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode. > > PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an > > die Nodes / Ways. > > > > > gerade weil man es nicht automatisch entscheiden kann, und weil relationen > prinzipiell komplexer sind als tags on nodes, würde ich tendenziell eher > einer PLZ an einem Node trauen als einer Relation. Alle PLZ die ich an > Nodes gehangen habe, kommen von Dingen wie Kassenzetteln oder in anderer > Weise von dem jeweiligen Nutzer (Internetseiten etc.). Klar kann man da > auch Fehler nicht ausschließen, von daher sollte nichts "automatisch" > gemacht werden, sondern diese Diskrepanzen durch Recherche aufgeklärt > werden. Wenn man aber rein auf Relationen setzt entgehen einem sicherlich > viele solcher Fehler und schlummern potentiell sehr lange in der db. Also irgendwie verstehe ich die Logik dahinter nicht. Aber mal von Anfang an: PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in diesem Gebiet für alle Grundstücke gültig. Damit gibt es eine eindeutige Zuordnung PLZ <--> Grundstück. Jetzt sagst Du das Du den PLZ an Nodes / Gebäuden / Ways mehr traust. Gut. Nur was heißt das? Die vorhandenen Daten sind nicht brauchbar, da nur mit Ortskenntnis oder mit 3. Mitteln die Korrektheit überprüft werden kann. Hier drängt sich die Frage auf: Warum werden potentiell falsche Daten erfasst? Ich denke mal hier sollte wie bei "is_in" die Relationen korrigieren und dann die addr:postcode Tags an den Nodes auslaufen lassen. Dafür spricht auch die leichtere Überprüfbarkeit, schnellere Korrektur und das verringerte Datenvolumen. Gruß Jörg -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
