@Mammi71 Danke. Die PostcodeMap habe ich gerade genauer angesehen. Hier wird die Postleitzahl nicht als fehlerhaft angesehen: OSM Postcode Map
Wahrscheinlich habe ich da tatsächlich einen Sonderfall erwischt, mit dem Gebäude, dass genau auf der Grenze sitzt.
Entscheidend ist die korrekte Adressierung des Gebäudes. Unter Umständen sollte die Postleitzahlengrenze dem angepasst werden und um das Gebäude drumherum geführt werden.
deine Overpass-Abfrage und meine Postcode Map kommen zu unterschiedlichen Ergebnissen, da deren Abfragen unterschiedlich sind.
Du fragst mit " way(r)" das Building als Polygon (Fläche) ab und dieses liegt mit einer winzigen kleinen Ecke im PLZ-Gebiet 56729. Das mag Overpass dazu verleiten, das Gebäude dort zu verorten.
Es könnte sein, dass bei einer Abfrage auf die PLZ 56745 das Gebäude auch dort verortet wird.
Keine Ahnung wie OVP bei grenzüberschreitenden Objekten vorgeht, da ich als PostgreSQL/PostGIS-Anwender kein Overpassisch spreche.
Meine Auswertung dagegen berechnet zuerst den Schwerpunkt des Polygons und arbeitet mit dieser Koordinate weiter
Vorschlag: nimm mal center(way(r)) oder ähnlich zur Abfrage
Gruß
walter
Ach ja: Das Autohaus hat wirklich die richtige PLZ
Bitte beachten: in den OSM Daten folgt die PLZ Grenze der Gemeindegrenze. Und die Gemeindegrenze ist in OSM sehr grob eingetragen. Einer anderen Datenquelle nach, welche aber für OSM nicht verwendbar ist, folgt die Grenze jedoch mehr oder weniger dem Flusslauf und schneidet kein Gebäude.
Zudem kann die PLZ-Grenze auch von den Gemeindegrenzen abweichen, möglicherweise für die Häuser südwestlich an der Straße Am Kehr, wo in OSM noch gar keine Adressen erfasst sind.
Hach, wunderbare Welt des Föderalismus mal wieder?
Hier in NRW zum Glück schon lange kein Problem mehr (mit einer kurzen Unterbrechung) da wir u.a. die ALKIS Katasterdaten des Landes als – kompatible – Datenquelle nutzen dürfen.
“Zudem kann die PLZ-Grenze auch von den Gemeindegrenzen abweichen” … ist zwar für kleine Gemeinden eher selten, aber am Ende (oder eher am Anfang?) des Tages bilden die Postleitzahlen halt Post-Zustellbezirke ab und keine Gemeindegrenzen, und wenn ein paar Gebäude am Ortsrand für den Zusteller des Nachbarortes deutlich einfacher zu erreichen sind kann das schon mal vorkommen wenn ich mich recht erinnere …
Mit meinem bisherigen Halbwissen, glaube ich, dass center nicht funktioniert. Ich erhalte zwar den Mittelpunkt von way(area.a)["addr:postcode"]["addr:postcode"!="56729"];, trotzdem wird der Way ja noch gefunden, weil die Koordinate einer Node im “falschen” Gebiet liegt.
Mein Bauchgefühl würde dies auch nur als Behelf ansehen. Korrekter wäre es in meinen Augen, die Grenze anzupassen.
Aber es gibt wohl, wenn ich @Mammi71 s Kommentar richtig lese, keine gesicherte und verwendbare Information zu den korrekten Postleitszahlgrenzen. Komisch, dass die Deutsche Post diese nicht bereitstellt?
Ist es überhaupt sinnvoll, die Postleitzahlen bei den einzelnen Adressen zu erfassen? Bläht das die OSM-Datenbank nicht nur unnötig auf? Warum ist Grenzrelation für die Postleitzahlen genau da? Ist das nicht eine redundante Information, welche man eigentlich vermeiden sollte?
Dann solltest du an deiner Abfrage noch ein wenig feilen. Ich weiss, dass das mit “center” oder “centroid” funktioniert., kann dir aber keine fertige Abfrage liefern.
IMHO gibt es keine offiziellen PLZ Polygone. Die offizielle Quelle für die PLZ ist die Datenbank der Deutschen Post AG die darauf ein Urheberrecht basierend auf dem Datenbankrecht erhebt.
Ob dieses Urheberrecht zu recht existiert ist strittig (Und auch Teil eines Gerichtsverfahrens) denn die Ursprünglichen Listen sind nicht von der Deutschen Post AG sondern von einer Bundesbehörde Veröffentlicht worden (1993 - Deutsche Bundespost - Postdienst - Bonn).
Die PLZ Grenzen die mal in OSM importiert wurden, wurden IMHO aus Adressbeständen quasi zurückgerechnet und nachbearbeitet.
Es macht aber Sinn beides zu haben - Du brauchst PLZ an den Adressen um das eben Adressscharf und ohne riesem Geometrieverarbeitung zu haben. Du brauchst geometrieen um in z.b. Webanwendungen die distanz zwischen 33428 und 33334 berechnen zu können (Zumindest näherungsweise).
Dazu kommt der erste Satz der Nachrichtentechnik: Redundanz schafft Sicherheit.
Für die maschinelle Auswertung ist eigentlich egal. Ein global nutzbares Programm muss eh beide Varianten unterstützen, sonst hat es riesige Lücken. Schwierig wird es dann, wenn man bei Konflikten entscheiden muss, ob man dem Anwender alle Varianten als mögliche Antwort präsentiert oder irgendwie die wahrscheinlichste berechnet.
Auf jeden Fall gut ist die Redundanz, um damit wahrscheinlich Copy+Paste Fehler zu finden oder andere Missgeschicke bei der Daten-Erfassung. Automatisierte Korrektur der Daten in OSM ist ja tabu.
Dazu der “erste” Satz der Informatik: Redundanz schafft Probleme .
Um erst keine Glaubenskriege aufkommen zu lassen: Beides hat seine Berechtigung.
Bei den PLZ bietet die Redundanz die Möglichkeit, fehlerhafte Zuweisungen zu erkennen, ganz vorne dran möchte ich da die Postcode Map erwähnen. Was stimmt, muss der Mapper entscheiden. Im Beispiel hier sieht es für mich eher so aus, dass die Grenze leicht verschoben werden muss, damit man nicht von Winzigkeiten in der Abfrage abhängig ist.
Hm. Ich habe es nicht geschafft mit center. Falls jemand weiß wie das geht oder einen Link zu einer Erklärung hat, würde ich mich freuen. Das wäre dann vielleicht auch etwas für das Wiki
Vielen Dank @chris66@flohoff@GerdP@seichter
Ich glaube nun verstehe ich das alles etwas besser.
Ich hatte auch den Satz “Redundanz ist schlecht” im Kopf.
Ich merke aber nun, wie immer gibt es für jede Sichtweise Vorteile und Nachteile.
