genau die und nur die. Muß aber nochmal die spatiale Abfrage checken, eventuell kommt da der Unterschied her.
edit: Nö, bin mir inzwischen sicher, daß die sauber ist:
select distinct postal_code
from planet_osm_polygon
where length(postal_code)=5
and st_contains((select way from planet_osm_polygon where osm_id=-51477),st_pointonsurface(way))
and boundary in ('postal_code','administrative')
and osm_id<0
order by postal_code;
Komisch. 02744 Oberoderwitz (Relation 1310441) ist nur “obsolete_boundary” getaggt. Warum ist die dabei?
Das ist bei vielen oder gar allen der Fall, die bei mir nicht dabei sind.
und damit ist das für die Auswertung eine admin-plz.
Den Fall hatte ich vor einigen Wochen bereits schon mal bei einer anderen PLZ-Relation. Damals konnte ich nur durch Tricks erreichen, dass der Datensatz korrigiert wurde.
Ich werde mich mal um diese Fälle kümmern. Damals half letztendlich nur ein Löschen und Neueintragen auf dem OSM-Server weiter, aber das möchte ich natürlich vermeiden.
In Sachsen wurden seit dem PLZ-Import 2010 etliche PLZ-Grenzen den admin-Grenzen angepasst.
Für mich sieht es so aus, dass OSMPC alle Relationen mit postal_code=* anzeigt.
Beispiel “08146 Mülsen-Ortmannsdorf”:
Das ist eine ehemalige PLZ-Relation, die von PLZ 08132 geschluckt wurde. Sie wurde trotz obsolete_boundary=postal_code angezeigt.
Mit obsolete_postal_code sollte sie aus OSMPC verschwinden.
Das Beispiel “02744 Oberoderwitz” ist eine admin-PLZ-Relation, die man über obsolete_postal_code ebenfalls aus der Zählung entfernen könnte.
Ich auch. Das wollte ich aber für das Ende der Aktion vorbehalten. Teils wurden nämlich veraltete PLZ fälschlich wieder in OSM eingeführt.
Ich hoffte, mit “obsolete_boundary” könnte man auf die offizielle Löschung besser hinweisen.
Aber so wichtig (und effektiv) ist das auch nicht. Wir können sie auch gleich löschen, wenn das mehr Vorteile bringt.
Sind wieder bei 8208. Habe die falsche (Postfach-)PLZ 03139 gefunden. (Frag nicht wie)
Das heißt natürlich nicht, dass es nicht auch noch weitere falsche geben kann.
EDIT: Und noch ne falsche PLZ: 04339 Engeldorf. Glücklicherweise ist das einfach zu korrigieren auf 04319 Leipzig und die Anzahl bleibt gleich.
EDIT 2: Mist, jetzt sind wir doch bei 8207. Musste 04454 Holzhausen löschen.
EDIT 3: Nochmal Mist: Jetzt sind es 8206. Musste 04460 Pegau löschen.
Seit Mai 2013 (Stand der Zahl 8208) wurden von der Post 3 PLZ entfernt (24875 Satrup, 98749 Neuhaus und 37534 Bad Grund). Danach müsste die aktuelle Anzahl 8205 sein.
Das hätte ich auch vorher schonmal checken können
Ich habe die OSM hiernach jetzt komplett aktualisiert (das im Juni gelöschte 98749 Neuhaus und natürlich 37534 Bad Grund von heute waren noch drin). Ich muss das noch mal gegenprüfen, komme aber zurzeit auf 8204 PLZ (Walter?). Das heißt, wir hätten eine zu wenig
Schön wäre es, wenn es für die PLZ so was ähnlich Verwertbares wie für Gemeindeschlüssel gäbe. Daraus wird unter MisterBoo GIS & Maps eine Map mit fehlenden/fehlerhaften/unvollständigen Relationen erstellt. (Oh je, da sah es schon mal besser aus …)
Schon eine textuelle Vergleichsliste (diff-artig mit Objekt-ID), was noch fehlt und was inzwischen zuviel ist, wäre hilfreich.
Momentan stoße ich eher zufällig, z.B. bei postal_code-Dubletten, auf Unstimmigkeiten.
Wobei die Referenz-Daten dort nicht sehr aktuell sind (März 2013). Daher sind die “Fehler” mir Vorsicht zu genießen. Schladen wurde z.B. zu Schladen-Werla.
Die aufgeführten gemeindefreien Gebiete mit Endung “444” sind nur interne Schlüssel und wohl nicht als admin-boundary getaggt. Dafür gibt es die offiziellen Relationen.
Wenn jemand die aktuelle Dez.-Liste von der Post hat, her damit!
