Danke schonmal für die zahlreiche Hilfe. Ich habe das Problem gleich mal als Anlass genommen mich in die Overpass QL einzuarbeiten Aber verstehe natürlich noch nicht alles…
Die Idee, die Rand nodes aus dem set zu nehmen und auf den Rest is_in anzuwenden klingt gut. Leider funktionierts aber bei couchmapper’s Vorschlägen (Post #9 und #13) noch nicht vollständig richtig.
Für die Gemeinde Merchweiler (“de:amtlicher_gemeindeschluessel”=“10043113”) erhält man in beiden Fällen die PLZ 66589, 66299, 66287. Laut Wikipedia ist 66589 richtig. Zunächst dachte ich, dass es sich hier um eine lokale Mapping Ungenauigkeit handelt, also dass die “Nachbar-PLZ-area” die Gemeindegrenze an einer Stelle nur um wenige Meter überschneidet. Ich habe mir dieses Beispiel in JOSM angesehen. Dem ist aber nicht so. Die Grenze zwischen PLZ 66589 und 66299 verläuft über die identischen nodes wie auch die Grenze der Gemeinde. Der Logik entsprechend sollte 66299 also nicht gefunden werden.
Wo steckt der Fehler?
Ah ok gut, ich hatte mich auch schon gefragt ob ich völlig blöd bin und erst (vor deinem hilfreichen Kommentieren) andere Ausgaben gesehen hatte
Nun gibt es noch solche Fälle, wie ich sie schon angesprochen habe:
Eppelborn (“de:amtlicher_gemeindeschluessel”=“10043111”) liefert die PLZ 66571 und 66822. Nur 66571 ist vermutlich richtig. Das liegt daran, dass lediglich das Gebiet einer Shell Tankstelle (ID 139856533), welche sich innerhalb der Eppelborn Fläche befindet, der PLZ 66822 zugeordnet ist. Der Rest dieser PLZ liegt außerhalb von Eppelborn.
Kann man diese “kleinen Ungenauigkeiten” herausfiltern, indem man verlangt, dass z.B. mindestens 50 nodes des sets innerhalb einer area mit dem tag “boundary”=“postal_code” liegen müssen?
Ich würde auf keinen Fall davon ausgehen, dass die Wikipedia-Angaben richtig/vollständig sind. Auch eine Abfrage bei der DPAG liefert nicht alle PLZ einer Gemeinde.
select -plz.osm_id, plz.note,-boundary.osm_id,boundary.name
from planet_osm_polygon plz,
planet_osm_polygon boundary
where boundary.boundary='administrative'
and plz.boundary = 'postal_code'
and length(boundary.tags->'de:amtlicher_gemeindeschluessel') >5
and st_intersects (boundary.way, plz.way)
order by boundary.name, plz.note;
Jo, ist logisch. Wieder mal das blöde st_intersects, was den Rand mit nimmt. Nun denn, dann buffern wir halt.
Die 2-3, die ich überprüft hatte, waren natürlich sauber
ach du grüne neune, da muß ich mich mal reinknien.
Danke für den Tip
walter
uii, wenn ich eine Testauswertung mit Eppelborn und Umgebung füttere, kommt tatsächlich das Richtige raus:
select -b.osm_id border,b.name,-p.osm_id pcborder,p.note
from planet_osm_polygon b,
planet_osm_polygon p
where b.osm_id in (-1187149)
and p.osm_id in (-3346971,-1184805,-1184803,-3348207,-3348209,-3348204)
and b.way && p.way
and ST_Relate(b.way,p.way,'T********')
order by b.name,b.osm_id desc, p.note
;
border | name | pcborder | note
---------+-----------+----------+-----------------
1187149 | Eppelborn | 1184803 | 66571 Eppelborn
1187149 | Eppelborn | 3348204 | 66822 Lebach
(2 rows)
select -b.osm_id,b.name,p.note
from planet_osm_polygon b,
planet_osm_polygon p
where b.boundary='administrative'
and p.boundary = 'postal_code'
and length(b.tags->'de:amtlicher_gemeindeschluessel') >5
and b.way && p.way
and ST_Relate(b.way,p.way,'T********')
order by b.name,b.osm_id desc, p.note;