Postleitzahl-Problematik

[Peter Wendorff]

Hi.
Da das Thema ein etwas größeres sein wird, will ich die
Postleitzahl-Problematik hier nochmal herausgreifen.
In der Vergangenheit wurde zu diesem Thema schon mehrfach diskutiert.

Das Problem in der eigentlichen Form:
Die Menge der Postleitzahlen steht in einer n:m-Beziehung zur
administrativen Ebene von
Orten/Gemeinden/Kreisen.../Staaten/Kontinenten, wodurch eine exakte
Abbildung der Postleitzahlengebiete auf die locids nicht so einfach
möglich ist.

Ich sehe zwei Möglichkeiten.

1) Verwendung der vorhandenen Struktur:
Jede Postleitzahl bekommt eine eigene loc_id in geodb_locations mit dem
Typ 100800000 (Postleitzahlgebiet). Die Zuordnung zu anderen locids, die
z.B. Orte etc darstellen, erfolgt nun über die "Teil von"-Typisierung
(400100000).
Beispiele dazu:
- Eine Postleitzahl mit locid 1 ist genau einer Stadt mit locid 2
zugeordnet, dann ist locid 1 teil von locid 2 und locid 2 teil von locid 1.
- Eine Postleitzahl mit locid 1 ist mehreren Orten/Städten (2 bis 5)
zugeornet, die aber alle nur diese Postleitzahl haben - dann ist 2 teil
von 1, 3 teil von 1, 4 teil von 1 und 5 teil von 1.
- Ein Ort, eine Gemeinde oder sonst irgendeine Struktur hat mehrere
Postleitzahlen - dann sind diese Postleitzahlen teil von dem Ort (...).
Grundsätzliche Ansatzmöglichkeit dazu wäre:
- erstmal sind alle Postleitzahlen Deutschlands teil von locid 105 (eben
Deutschland)
- kann man einige Postleitzahlen davon eingrenzen (z.B. sind alle
Postleitzahlen mit 40***, 41***, 42***, 44***, 45***, 46***, 47***...
Postleitzahlen in NRW), so werden diese als teil des entsprechenden
Eintrages (NRW: 117) gesetzt.
Da A teil von B teil von C auch A teil von C impliziert, ist dieses
Vorgehen immer gültig und trägt der mehr oder weniger guten Genauigkeit
der Daten Rechnung.

Ich weiß nicht, wie praktikabel dieser Ansatz wäre, aber ich halte es
zumindest für eine Möglichkeit.

2) Verwendung einer zusätzlichen Struktur für Postleitzahlen, da diese
sich eben nicht in die Verwaltungsstrukturen der Staaten einfügen.
Dazu könnte man neue Tabellen einführen, genauer ausgedacht hab ich mir
das noch nicht.

Ich plädiere auch eher für den ersten Ansatz - wenn ich da nicht
irgendwo gravierende Denkfehler gemacht habe.
Für die Anwendung von Suchabfragen:

Problemtyp 1) Ich habe eine Postleitzahl p und möchte dazu passende Orte
haben:
Lösung: Man suche alle Orte/Einträge x, bei denen die p Teil von x ist
(x hat mehrere Postleitzahlen, darunter p), und alle Einträge, bei denen
x teil von p ist (p ist mehreren Orten zugeordnet, darunter x).

Problemtyp 2) Ich habe einen Ort x und suche dazu passende Postleitzahlen:
Lösung: Teil-von-Beziehung zwischen dem Ort und locids vom Typ
Postleitzahlgebiet in beliebige Richtung, also alle Einträge mit typ
"teil von", loc_id x - gesuchte loc_ids sind dann in text_val (bzw.
später int_val) zu finden.

Um die Ergebnislisten auf Entfernungen einzuschränken, kann man in den
gefundenen Mengen jeweils noch die Entfernung der Koordinaten
voneinander berechnen und als weiteres Kriterium hinzuziehen.

Auch hier bitte ich um Diskussionsteilnehmer ;)

Gruß
Peter Wendorff
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Peter Wendorff wrote:

> Hi.
> Da das Thema ein etwas größeres sein wird, will ich die
> Postleitzahl-Problematik hier nochmal herausgreifen.
> In der Vergangenheit wurde zu diesem Thema schon mehrfach diskutiert.
>
> Das Problem in der eigentlichen Form:
> Die Menge der Postleitzahlen steht in einer n:m-Beziehung zur
> administrativen Ebene von
> Orten/Gemeinden/Kreisen.../Staaten/Kontinenten, wodurch eine exakte
> Abbildung der Postleitzahlengebiete auf die locids nicht so einfach
> möglich ist.
>
> Ich sehe zwei Möglichkeiten.
>
> 1) Verwendung der vorhandenen Struktur:
> Jede Postleitzahl bekommt eine eigene loc_id in geodb_locations mit dem
> Typ 100800000 (Postleitzahlgebiet).

Das ist der Stand bis 0.2.4 bzw. der Wiki-Stand in der PLZ.tab

> Die Zuordnung zu anderen locids, die
> z.B. Orte etc darstellen, erfolgt nun über die "Teil von"-Typisierung
> (400100000).

Das wäre denkbar - aber was will man damit gewinnen? Es gibt
Postleitzahlen, die Bundesland-übergreifend verlaufen!

Das einfachere ist für mich die Verlinkung von der PLZ eines normalen
opengeodb-Eintrags über die PLZ selbst zu einem entsprechenden PLZ-Gebiet.

Sehe ich mir das SQL-geeiere an, die Verwirrung um die Datentypen usw.,
so würde ich an der Stelle dafür plädieren, besser gleich eine eigene
Tabelle anzulegen mit z.B.

create table geodb_plzdata (
   loc_id               integer,
   plz_val              varchar(5), /* für Deutschland nur fünf Ziffern),
   text_locale          varchar(5), /* ISO 639-1 */
   text_val             varchar(255),
   lat                  double precision,
   lon                  double precision,
   valid_since          date,
   date_type_since      integer,
   valid_until          date not null,
   date_type_until      integer not null,
) TYPE=InnoDB CHARACTER SET utf8;

Ich weiss nicht, ob in einer Tabelle die PLZ jedes Landes genutzt werden
sollte oder ob je Land eine eigene Tabelle angelegt werden sollte. Durch
die klare Trennung von einer geodb_plzdata zu einer geodb_textdata oder
gar geodb_hierarchies könnte man erheblich deutlicher machen, dass
PLZ-Strukturen mit opengeodb-Strukturen wenig gemein haben.

> Beispiele dazu:
> - Eine Postleitzahl mit locid 1 ist genau einer Stadt mit locid 2
> zugeordnet, dann ist locid 1 teil von locid 2 und locid 2 teil von locid 1.
> - Eine Postleitzahl mit locid 1 ist mehreren Orten/Städten (2 bis 5)
> zugeornet, die aber alle nur diese Postleitzahl haben - dann ist 2 teil
> von 1, 3 teil von 1, 4 teil von 1 und 5 teil von 1.
> - Ein Ort, eine Gemeinde oder sonst irgendeine Struktur hat mehrere
> Postleitzahlen - dann sind diese Postleitzahlen teil von dem Ort (...).
> Grundsätzliche Ansatzmöglichkeit dazu wäre:
> - erstmal sind alle Postleitzahlen Deutschlands teil von locid 105 (eben
> Deutschland)
> - kann man einige Postleitzahlen davon eingrenzen (z.B. sind alle
> Postleitzahlen mit 40***, 41***, 42***, 44***, 45***, 46***, 47***...
> Postleitzahlen in NRW), so werden diese als teil des entsprechenden
> Eintrages (NRW: 117) gesetzt.
> Da A teil von B teil von C auch A teil von C impliziert, ist dieses
> Vorgehen immer gültig und trägt der mehr oder weniger guten Genauigkeit
> der Daten Rechnung.

Gegenbeispiel: die "reingeschneiten" Postleitzahlen: Bauernhof H liegt
auf der Gemarkung von Landkreis L, wird aber postalisch versorgt durch
die Kreisstadt K.

H ist also Teil von L und hat Postleitzahl locid 1.
L hat aber - mit Ausnahme von H - nur die PLZ locid 2.
K hat ganz normal die PLZ locid 1 - und sonst keiner, mit Ausnahme von H.

Ist H nun Teil von K?
Ist die PLZ locid 2 nun tatsächlich zugehörig zu L?

Ich sehe das viel pragmatischer:
L muss nicht die PLZ locid 2 nennen, auch wenn der Teil H von L diese
PLZ kennt.

Eintrag  PLZ Teil von
L        2   B
H        1   L
K        1   B

> Ich weiß nicht, wie praktikabel dieser Ansatz wäre, aber ich halte es
> zumindest für eine Möglichkeit.

Sicher ist es eine Möglichkeit. Aber ist sie auch besser als der
bisherige Ansatz?


> Für die Anwendung von Suchabfragen:
>
> Problemtyp 1) Ich habe eine Postleitzahl p und möchte dazu passende Orte
> haben:
> Lösung: Man suche alle Orte/Einträge x, bei denen die p Teil von x ist
> (x hat mehrere Postleitzahlen, darunter p), und alle Einträge, bei denen
> x teil von p ist (p ist mehreren Orten zugeordnet, darunter x).

Meinst du hier explizit die "Teil von"-Beziehung oder  - so wie bisher -
einfach die Suche im Feld PLZ eines opengeodb-Eintrags textdata, type
500300000 und dann das Heraussuchen (über die loc_id) des zugehörigen
Namens aus 500100000

> Problemtyp 2) Ich habe einen Ort x und suche dazu passende Postleitzahlen:
> Lösung: Teil-von-Beziehung zwischen dem Ort und locids vom Typ
> Postleitzahlgebiet in beliebige Richtung, also alle Einträge mit typ
> "teil von", loc_id x - gesuchte loc_ids sind dann in text_val (bzw.
> später int_val) zu finden.

Bisher geht das eben einfach durch die Suche nach Ort x und die Ausgabe
der zugehörigen (laut loc_id) 500300000-Werte.

Ich kann noch keinen deutlichen Vorteil deiner Alternative erkennen -
weder in der Übersichtlichkeit noch in der Effizienz

> Um die Ergebnislisten auf Entfernungen einzuschränken, kann man in den
> gefundenen Mengen jeweils noch die Entfernung der Koordinaten
> voneinander berechnen und als weiteres Kriterium hinzuziehen.

Die anscheinend typische Aufgabe ist wohl sehr oft
Problemtyp 3) Umkreissuche nach nächstgelegener PLZ

Gegeben ist ein Adressverzeichnis - herausgesucht werden die dazu
passenden Koordinaten, z.B. über die PLZ.

Gesucht wird dann nach der nächstgelegenen Adresse zu einer PLZ-Eingabe.
Da kann man sich überlegen, ob man nur fünfstellige Eingaben zulässt
oder auch die Beschränkung auf die ersten Stellen, ob Wildcards erlaubt
sind, ob nur gültige PLZ-Angaben erlaubt sind usw.

Ich selbst mache es so, dass ich fünfstellige PLZ-Angaben erwarte. Bei
einer ungültigen PLZ wird die nächst höhere, gültige verwendet.

Bei genau passender PLZ setze ich die Entfernung gleich auf Null - auch
wenn für eine Adresse genauere Koordinaten vorliegen als nur die des
PLZ-Gebiets und damit eigentlich eine Entfernung größer Null zwischen
PLZ- und Adresskoordinaten vorliegen. Andernfalls mache ich eine
Umkreissuche - in meinem Fall schränke ich den Radius auf z.B. 20 km ein
(das hängt je nach Anwendung von der Adressdichte ab) und ermittle damit
min/max-Werte für lat/lon. Ich berechne die Entfernung dann auch nur für
die entsprechend passenden Treffer, sortiere die nach Entferung und gebe
die davon besten aus - alles ohne SQL, direkt als perl-Script auf PLZ.tab:
http://fa-technik.adfc.de/code/anbieter
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)