Aktualität von PLZ-Daten am Beispiel

Wie kamst du zu diesem Schluss? Einen sinnvollen Grund kann ich in deinem Beitrag nicht erkennen.

aighes wrote:

Wie kamst du zu diesem Schluss? Einen sinnvollen Grund kann ich in deinem Beitrag nicht erkennen.

Ich habe einen Bekannten gefragt, der dort wohnt. Außerdem habe ich die Adresse bei der PLZ-Suche der Post eingegeben
und ja auch die Mitteilungsblätter durchforstet (daher die Datumsangabe 2008).

Die Verwendung eines "check_date"-Tags könnte neben "source" auch helfen, die Gültigkeit von Daten zu überprüfen.

Gehrke wrote:

Im Rahmen einer Korrektur sich überlappender PLZ-Gebiete stieß ich mal wieder auf völlig veraltete Daten.
Konkret: Straße Brückenkopf in Lutherstadt Wittenberg. Laut Post gilt hier seit Dez. 2008 die PLZ 06888.

OSM und die Website der dortigen Herberge/Camp sagen 06886. Was ist korrekt?

Man sollte ja annehmen, dass Leute, die dort wohnen, es am besten wissen (einer der OSM-Grundsätze).
Vielleicht hat man auch seit 2008 die Website nicht mehr aktualisiert. Möglich immerhin.
Aber der Verlauf der PLZ-Grenze in OSM sollte doch ein Import mit Stand 2010 sein - also hier eigentlich korrekt.

Ich weiss nicht, wie du OSM "gefragt" hast, aber das Gebiet "Brückenkopf" ist im PLZ-Gebiet 06888 erfasst. Zu sehen auf meiner PLZ-Karte
Aufgrund technischer Probleme sind die hier angezeigten Daten ca 330 Stunden alt, stellen damit den Datenbestand vor deinen Änderungen dar.

Ich bin nun zu dem Schluss gekommen, dass die OSM-Daten hier falsch sind (bzw. waren) und habe es geändert.

Du hat die PLZ eines veralteten Nodes korrigiert; dazu ein großes Lob.

Damit enthielt OSM Daten, die schon fast 5 Jahre nicht mehr gelten!

Ja, und wenn der PLZ-Tag an den Buildings und nicht an der Camp-Site (*) stünde, wäre es in der Karte sofort aufgefallen. Sogar ein postal_code an der Straße "Brückenkopf" hätte sich "gemeldet". Aber auf Campingplätze ist mein Programm leider nicht eingestellt.

Es gibt da ein Stück von Shakespeare, nur fällt mir der Name gerade nicht ein 😉

Gruss
walter

• ) einfach mal mit dem Cursor über das Zelt "fahren".
  

warum so negativ? Ich glaube er hat nur nicht verstanden, dass sich die PLZ der Objekte nicht aktualisieren, wenn man die PLZ Grenze anpasst.

SunCobalt wrote:

warum so negativ? Ich glaube er hat nur nicht verstanden, dass sich die PLZ der Objekte nicht aktualisieren, wenn man die PLZ Grenze anpasst.

Nun ja, aber anschliessend über die Schrott-Daten in OSM beschweren.

Sorry, mag auch an meiner derzeit schlechten Laune liegen. 2 Tage Fehlersuche in der DB, die sich nicht mehr starten ließ. Was wars? Upgrade von Ubuntu auf 13.10 hat die Access-Rechte zweier Mini-Files im SSL-Umfeld geändert, sodas postgres nicht mehr seinen SSL-Key belesen konnte und dann kommentarlos abgefackelt ist. Schreibt noch netterweise hin "postgresql liess sich nicht starten. Fehlerbeschreibungen stehen im LOG-File". Und das Log-File war natürlich leer.
Hab mal wieder einiges über strace, shell-Programmierung, forks, Perl und Debugging gelernt - also alles war man für das Betreiben eine SQL-Datenbank unbedingt braucht 🙁

Puh, das musste raus.

Gruss
walter

wambacher wrote:

Ich weiss nicht, wie du OSM "gefragt" hast, aber das Gebiet "Brückenkopf" ist im PLZ-Gebiet 06888 erfasst.

Vorher war das eigentlich nicht so. Alle entsprechenden Tags (camp_site und Straße) sollten erst heute von mir gesetzt worden sein.
Die Relation sowieso.

SunCobalt wrote:

Ích glaube er hat nur nicht verstanden, dass sich die PLZ der Objekte nicht aktualisieren, wenn man die PLZ Grenze anpasst.

Er ist ja nicht blöd.

Nahmd,

Gehrke wrote:

SunCobalt wrote:

Ích glaube er hat nur nicht verstanden, dass sich die PLZ der Objekte nicht aktualisieren, wenn man die PLZ Grenze anpasst.

Er ist ja nicht blöd.

Genau.

Gruß Wolf

Gehrke wrote:

wambacher wrote:

Ich weiss nicht, wie du OSM "gefragt" hast, aber das Gebiet "Brückenkopf" ist im PLZ-Gebiet 06888 erfasst.

Vorher war das eigentlich nicht so. Alle entsprechenden Tags (camp_site und Straße) sollten erst heute von mir gesetzt worden sein.
Die Relation sowieso.

Stimmt: bei der Relation hab ich mich versehen, da war wirklich einiges nicht in Ordnung. Musste erst bei der Post "spicken" um das Problem zu erkennen.

btw: EIN Teil der Straße "Brückenkopf" hat von dir einen postal_code erhalten, der andere Teil zur Hauptstraßevorhin von mir.

mein QA-Tool hat da leider "versagt". Mal sehen, ob ich da was machen kann. Technisch sicher kein Problem; ich möchte nur nicht, daß mir die schon geringe Performance ganz zusammenbricht. Es zeigt den camp_site Node schon an, nur mit dem veralteten Wert 06886. Und da hier sowohl Relation als auch der Node falsch waren, konnte das nicht auffallen. Die PLZ-Karte zeigt "falsche" PLZ im"richtigen" Gebiet an. Aber wenn nun beides falsch ist, sieht das natürlich sauber aus. 🙁

Sorry für die unnötige Verwirrung und Shakespeare soll auch schon lange tot sein.

gruss
walter

EDIT: große Korrektur meiner teilweisen falschen Aussage.

Nahmd,

wambacher wrote:

ich möchte nur nicht, daß mir die schon geringe Performance ganz zusammenbricht.

Möglicherweise empfiehlt sich da, die Anfragen über mehrere Datenbanken zu verteilen.

Du kannst jederzeit in einem Programm mehrere Datenbanken parallel aufmachen und Queries über beide gleichzeitig machen.

siehe: http://www.unityjdbc.com/doc/multiple/multiplequery.php
und für postgresql im Speziellen: http://www.postgresql.org/docs/9.1/inte … blink.html

Immer konstruktiv und hilfreich: Wolf