Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

stephan75 · 2011-06-17 05:30:53

Hi,

z.B. im Nord-Osten von Niedersachsen fehlen noch für etliche Gemeinden die Grenzpolygone als Relationen, zu sehen z.B. unter http://tools.geofabrik.de/osmi/?view=bo … ndary_ways

Was für diese Gebiete aber schon existiert, sind die PLZ-Grenzen aus dem Import von http://wiki.openstreetmap.org/wiki/Impo … hland_2010 , zu sehen unter http://tools.geofabrik.de/osmi/debug.ht … ys=plz_osm

Es gibt nun einige kleine Gemeinden, bei denen sind die bereits erfassten PLZ-Grenzen identisch mit den Gemeindegrenzen. Somit könnten die PLZ-Grenzen ja auch als boundary=administrative dienen. Wie gesagt: nur dort wo die Grenzen tatsächlich identisch wären.

Für den Landkreis Lüneburg findet sich hier mal eine Zusammenstellung: http://wiki.openstreetmap.org/wiki/L%C3 … Relationen

Meine Idee / Frage:

Z.B. für den Ort Deutsch Evern habe ich den Schlüssel boundary=postal_code auf =administrative geändert sowie admin_level=8 hinzugefügt.

d.H. für BEIDE Grenzarten (politisch und PLZ) existiert jetzt nur EINE Relation. Ist das so in Ordnung?

Oder sollten für PLZ-Grenzen und Gemeindegrenzen (bei Deckungsgleichheit!) doch je eine eigene (dann wohl inhaltsgleiche) Relation einmal mit boundary = administrative und einmal mit
boundary = postal_code angelegt werden (bzw. so belassen werden)?

Wie habt ihr das in anderen Gegenden der Republik gemacht? Was sagt Taginfo oder Tagwatch dazu?

Kernfrage also: EINE oder ZWEI Relationen?

Gruß, Stephan

GeorgFausB · 2011-06-17 07:10:00

Moin,

eine.
Stellen sich irgendwann wirklich Unterschiede heraus, kann man sie immer noch trennen.

Gruß
Georg

tiototo · 2011-06-17 07:36:07

Solche Gemeinden oder Städte gibts viele - Du hast den Value geändert? Sprich es gibt nun keinen postal_code mehr? Das wäre blöd. Ich nehm mal eher an Du hast da etwas ergänzt. Dann ist der Schlüssel aber doppelt belegt. Ich hab hier Software die sucht nach dem postal_code und dann gäbe es Ecken die hätten dann gar keinen mehr.

GeorgFausB · 2011-06-17 08:25:05

Moin,

1) steht es doch ganz eindeutig da:

boundary=postal_code auf =administrative geändert sowie admin_level=8 hinzugefügt

2) kann man es ganz einfach bei "Deutsch Evern" nachprüfen:

Der postal_code = 21407 blieb davon unverändert.

Da braucht man nichts anzunehmen ... und sich auch nicht um ungelegte Eier zu sorgen.

Gruß
Georg

wambacher · 2011-06-17 08:30:49

stephan75 wrote:

Z.B. für den Ort Deutsch Evern habe ich den Schlüssel boundary=postal_code auf =administrative geändert sowie admin_level=8 hinzugefügt.
d.H. für BEIDE Grenzarten (politisch und PLZ) existiert jetzt nur EINE Relation. Ist das so in Ordnung?

Hi stephan,

ist absolut ok so und auch korrekt getaggt.

weiter so.

gruss
walter

p.s: kennst du das?
http://wnordmann.homeunix.com/index.php/osm
server ist nicht der schnellste und auch nicht 7/24 up aber beides ändert sich bald.

tiototo · 2011-06-17 11:30:46

Nur mal eben dass ich das richtig verstehe. Wenn ich von einem Punkt wissen will in welcher PLZ der liegt dann reicht das nicht dass ich boundary=postal_code suche sondern muss außerdem noch nach postal_code=XXXXX gucken? Oder hat sowie jedes PLZ-taugliche Polygon ein postal_code=XXXXX und ich kann mir die Abfrage mit dem boundary sparen? Dann frag ich mich warum es überhaupt noch den Fall das Tag boundary=postal_code gibt. Was wertet Mapnik denn aus?

wambacher · 2011-06-17 11:47:36

tiototo wrote:

Nur mal eben dass ich das richtig verstehe. Wenn ich von einem Punkt wissen will in welcher PLZ der liegt dann reicht das nicht dass ich boundary=postal_code suche sondern muss außerdem noch nach postal_code=XXXXX gucken? Oder hat sowie jedes PLZ-taugliche Polygon ein postal_code=XXXXX und ich kann mir die Abfrage mit dem boundary sparen? Dann frag ich mich warum es überhaupt noch den Fall das Tag boundary=postal_code gibt. Was wertet Mapnik denn aus?

boundary=* definiert, WAS für eine Grenze das ist:
- ortsgrenze: boundary=administrative
- plz-grenze: boundary=postal_code
- beides: adminstrative ist "stärker"

der rest steht hier: http://wiki.openstreetmap.org/wiki/Impo … hland_2010

gruss
walter

stephan75 · 2011-06-17 12:07:24

Wie ist denn bisher der Status Quo in Deutschland?

Gibt es Gebiete, wo es zwar boundary=administrative (ggf. it postal_code =XXXXX), aber KEINE boundary=postal_code Multipolygone gibt?

Oder auch "boundary=administrative;postal_code" ???

tiototo · 2011-06-17 12:56:29

wambacher wrote:

der rest steht hier: http://wiki.openstreetmap.org/wiki/Impo … hland_2010

Danke für den Link, sehr interessant. Wenn ich das richtig verstehe, ist das Ziel, alles mit postal_code=XXXXX zu haben.
Fürs nächste Update ist der Schlüssel dann auch für meine Datenbank vorgemerkt, der default.style für osm2pgsql hat das normal nämlich nicht drin. Demnach hat Mapnik die PLZ-Grenzen noch aus der "alten" Schreibweise oder ich hab nicht die aktuelle Datei.

wambacher · 2011-06-17 13:04:55

stephan75 wrote:

Wie ist denn bisher der Status Quo in Deutschland?
Gibt es Gebiete, wo es zwar boundary=administrative (ggf. it postal_code =XXXXX), aber KEINE boundary=postal_code Multipolygone gibt?

ja klar, immer dort wo plz-grenze=gemeinde-grenze ist. da sind 2 MP absolut unnötig - und das war ja auch tiotot's Frage.

Oder auch "boundary=administrative;postal_code" ???

auf keinen Fall!! wenn du sowas finden solltes, bitte ändern
könntest dir das wiki - genauso wie diesen mini-thread nochmal durchlesen.

gruss
Walter

Fabi2 · 2011-06-20 01:20:54

stephan75 wrote:

Oder sollten für PLZ-Grenzen und Gemeindegrenzen (bei Deckungsgleichheit!) doch je eine eigene (dann wohl inhaltsgleiche) Relation einmal mit boundary = administrative und einmal mit
boundary = postal_code angelegt werden (bzw. so belassen werden)?

Zwei Relationen. Weil bei einer müßte man ja nach dem derzeitigen Schema boundary=administrative;postal_code in die Relation schreiben. Interessanterweise wird Taggimg mit dem ";"-Separator hier von manchen Leuten jetzt nicht so toll gefunden, wo sie es an anderer Stelle angeblich OK ist. Entscheidet euch doch mal!

Wenn ich boundary=administrative benutze, wie bekomme ich denn dann die Postleitzahlrelationen, wenn ich eine Abfrage nach boundary=postal_code mache? Zwar bekommt man die Postleitzahlen noch mit einem Filter nach Relationen mit postal_code=* aus der Datenbank, aber von einem ordentlichen Schema oder Abfragestil ist das weit entfernt, ähnliches gilt ersatzweise für admin_level=* . Da bleibt also nur zwei Relationen zu erstellen, damit es sauber ist.

stephan75 · 2011-06-20 06:17:02

Fabi2 wrote:

stephan75 wrote:
Oder sollten für PLZ-Grenzen und Gemeindegrenzen (bei Deckungsgleichheit!) doch je eine eigene (dann wohl inhaltsgleiche) Relation einmal mit boundary = administrative und einmal mit
boundary = postal_code angelegt werden (bzw. so belassen werden)?
Zwei Relationen. Weil bei einer müßte man ja nach dem derzeitigen Schema boundary=administrative;postal_code in die Relation schreiben. Interessanterweise wird Taggimg mit dem ";"-Separator hier von manchen Leuten jetzt nicht so toll gefunden, wo sie es an anderer Stelle angeblich OK ist. Entscheidet euch doch mal!
Wenn ich boundary=administrative benutze, wie bekomme ich denn dann die Postleitzahlrelationen, wenn ich eine Abfrage nach boundary=postal_code mache? Zwar bekommt man die Postleitzahlen noch mit einem Filter nach Relationen mit postal_code=* aus der Datenbank, aber von einem ordentlichen Schema oder Abfragestil ist das weit entfernt, ähnliches gilt ersatzweise für admin_level=* . Da bleibt also nur zwei Relationen zu erstellen, damit es sauber ist.

Jaaaaa, du bist der erste, der auch mal "von der anderen Seite her" argumentiert, Danke.

Ich finde, da sollte über kurz oder lang mal eine festere Definition gefunden werden, ob nun eine Relation für beides oder jeweils eine eigene.

Könnte mal jemand, wer die "Problematik" auch generell sieht, das vielleicht auf der de-Mailingliste anstoßen?

Wie verhält es sich denn in anderen Staaten? und welche Applikationen werten denn bisher auch die PLZ-Relationen aus?

viw · 2011-06-20 07:12:06

Fabi2 wrote:

stephan75 wrote:
Oder sollten für PLZ-Grenzen und Gemeindegrenzen (bei Deckungsgleichheit!) doch je eine eigene (dann wohl inhaltsgleiche) Relation einmal mit boundary = administrative und einmal mit
boundary = postal_code angelegt werden (bzw. so belassen werden)?
Zwei Relationen. Weil bei einer müßte man ja nach dem derzeitigen Schema boundary=administrative;postal_code in die Relation schreiben. Interessanterweise wird Taggimg mit dem ";"-Separator hier von manchen Leuten jetzt nicht so toll gefunden, wo sie es an anderer Stelle angeblich OK ist. Entscheidet euch doch mal!
Wenn ich boundary=administrative benutze, wie bekomme ich denn dann die Postleitzahlrelationen, wenn ich eine Abfrage nach boundary=postal_code mache? Zwar bekommt man die Postleitzahlen noch mit einem Filter nach Relationen mit postal_code=* aus der Datenbank, aber von einem ordentlichen Schema oder Abfragestil ist das weit entfernt, ähnliches gilt ersatzweise für admin_level=* . Da bleibt also nur zwei Relationen zu erstellen, damit es sauber ist.

Also ich denke in einem ordentlichen Schema braucht es keine doppelten Informationen. Es würde also genügen admin_level= zu definieren oder postal_code=
Welchen Vorteil habe ich jetzt von einem Tag namens boundary= ? Eigentlich keinen.
Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=... Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

tiototo · 2011-06-20 07:44:23

Ich bin auch für zwei Relationen, allein um die alten Daten vom Import noch zu haben. Wenn aber beschlossen ist alles auch Gebiete umzustellen, an die ich über postal_code=xxxxx rankomme soll mir das auch recht sein. Wichtig ist nur dass man eine Abfrage machen kann, wo man zu einem Punkt die PLZ bekommen kann, das muss funktionieren!

ajoessen · 2011-06-20 07:56:02

viw wrote:

Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=... Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

Sehe ich anders:

Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.

Gruß,
ajoessen

viw · 2011-06-20 08:03:00

ajoessen wrote:

viw wrote:
Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=... Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.
Sehe ich anders:
Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.
Gruß,
ajoessen

also ich weiß nicht wie genau Osmosis filtert, aber bei o5mfilter kann ich statt nach type=route auch nach route= filtern. und damit hätte ich fast das Gleiche Ergebnis. Wenn in einem zweiten Schritt dann nach route=bus gesucht wird sogar wieder ein identisches.
Aber wahrscheinlich unterstützt auch Osmosis einen Filter nach route=*
Also bei Punkten und Wegen gibt es statt key value auch nur die Option nach key zu suchen. Für Relationen konnte ich das leider nicht finden.
Der einzige Unterschied ist das alle Relationen rausfliegen, welche nur mit type=route getagt sind und nicht weiter spezifiziert wurden. Diese brauchst du aber in deinem Beispiel nicht.
Auch der Umkehrschluss, dass jemand alle Relationen mit type=route raus haben möchte ließe sich über den key route=* lösen. Ich kann also den Sinn nicht erkennen.

Last edited by viw (2011-06-20 08:05:10)

GeorgFausB · 2011-06-20 08:20:18

Moin,

ajoessen wrote:

viw wrote:
Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.
Sehe ich anders:
Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.

Ihr solltet schon Gleiches mit Gleichem vergleichen:
Dem Wortlaut nach hat viw recht - solange er nur eine Unterkategorie in allen Relationen sucht (dies ist die Analogie zu postal_code und admin_level).
Andre hat recht - wenn er mehrere Unterkategorien von route bearbeiten möchte. (Dies ist der Unterschied bei ÖPNV - road ist wieder eigentlich nur eine Einzelunterkategorie).

Bei den Relationen mit nur einer Unterkategorie ist der Aufwand identisch, ob man nun nach Relations-Typ oder nach tatsächlicher Eigenschaft sucht - von daher sind die eigenen Relationen (für postal_code und admin_level bei identischem Verlauf) zwar Ariel-reines Schema - aber eigentlich nur Selbstzweck.

Gruß
Georg

Last edited by GeorgFausB (2011-06-20 08:22:40)

viw · 2011-06-20 08:26:02

GeorgFausB wrote:

Moin,
Ihr solltet schon Gleiches mit Gleichem vergleichen:
Dem Wortlaut nach hat viw recht - solange er nur eine Unterkategorie in allen Relationen sucht (dies ist die Analogie zu postal_code und admin_level).
Andre hat recht - wenn er mehrere Unterkategorien von route bearbeiten möchte. (Dies ist der Unterschied bei ÖPNV - road ist wieder eigentlich nur eine Einzelunterkategorie).
Bei den Relationen mit nur einer Unterkategorie ist der Aufwand identisch, ob man nun nach Relations-Typ oder nach tatsächlicher Eigenschaft sucht - von daher sind die eigenen Relationen (für postal_code und admin_level bei identischem Verlauf) zwar Ariel-reines Schema - aber eigentlich nur Selbstzweck.
Gruß
Georg

Wo ist der Unterschied? Ich möchte alle Straßen haben. Ich suche also nach highway=*. Ich möchte alle Routen haben ich suche also nach route=*.
Heute kann ich alle Routen aber zusätzlich mit type=route finden. Und genau dieses überflüssige type=route kann man sparen.
Ja ich weiß Josm filtert danach und sortiert die unterschiedlichen types. Aber das kann man anpassen!

wambacher · 2011-06-20 09:56:33

stephan75 wrote:

und welche Applikationen werten denn bisher auch die PLZ-Relationen aus?

u.A. meine http://wnordmann.homeunix.com/otm/plz1.html
und das ohne Probleme, solange ihr hier nur diskussiert aber nichts gravierendes ändert.
Grosse Sorgen mach ich mir aber nicht, da aus solchen "man müsste, man sollte, im wiki müsste man"-Diskussionen fast nie was rauskommt.

Gegen eine Vereinfachung hab ich allerdings nichts einzuwenden.

Gruss
Walter

viw · 2011-06-20 10:07:42

wambacher wrote:

stephan75 wrote:
und welche Applikationen werten denn bisher auch die PLZ-Relationen aus?
u.A. meine http://wnordmann.homeunix.com/otm/plz1.html
und das ohne Probleme, solange ihr hier nur diskussiert aber nichts gravierendes ändert.
Grosse Sorgen mach ich mir aber nicht, da aus solchen "man müsste, man sollte, im wiki müsste man"-Diskussionen fast nie was rauskommt.
Gegen eine Vereinfachung hab ich allerdings nichts einzuwenden.
Gruss
Walter

So dann werde mal konkret. Welche Vereinfachungen Deiner Meinung nach zulässig werden und ab wann eine Auswertbarkeit Verloren geht?

wambacher · 2011-06-20 11:42:26

viw wrote:

So dann werde mal konkret. Welche Vereinfachungen Deiner Meinung nach zulässig werden und ab wann eine Auswertbarkeit Verloren geht?

so könnte es aussehen:

./.                   Admin           PLZ                  beides
type                  boundary        boundary             boundary
boundary              administrative  postal_code          administative 
admin_level           *               -                    *
postal_code           -               *                    *

- type=multipolygon ist eine "Null-Information", die imho nicht notwendig ist.
Es handelt sich hier um eine Relation, deren interne Struktur bereits aus den Members hervorgeht.
Das ist ein Multipolygon; das braucht man nicht nochmal dranzuschreiben.
Es muss nur klar sein, dass es sich um eine beliebige Art von Grenze handellt.

- beide Informationen in eine Relation reinzuschreiben erscheint mir irgendwie unsauber; dadurch sind schon speziellere Abfragen notwendig.
Andererseits ist das Erfassen/Pflegen der Rels einfacher.

Erst wollte ich type sogar ganz weglassen aber es gibt noch andere Rels mit postal_code (z.B. associatedStreet)

Das ist mein Vorschlag:

./.                   Admin           PLZ
type                  boundary        boundary                
boundary              administrative  postal_code    
admin_level           *               -                    
postal_code           -               *

rein theoretisch könnte man sogar noch boundary=* weglassen.

./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter

viw · 2011-06-20 11:51:18

wambacher wrote:

./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter

./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

SunCobalt · 2011-06-20 11:55:39

viw wrote:

./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

viw · 2011-06-20 11:59:37

SunCobalt wrote:

viw wrote:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

SunCobalt · 2011-06-20 12:04:08

viw wrote:

SunCobalt wrote:
viw wrote:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?
Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Announcement

#1 2011-06-17 05:30:53

Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#2 2011-06-17 07:10:00

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#3 2011-06-17 07:36:07

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#4 2011-06-17 08:25:05

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#5 2011-06-17 08:30:49

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#6 2011-06-17 11:30:46

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#7 2011-06-17 11:47:36

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#8 2011-06-17 12:07:24

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#9 2011-06-17 12:56:29

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#10 2011-06-17 13:04:55

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#11 2011-06-20 01:20:54

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#12 2011-06-20 06:17:02

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#13 2011-06-20 07:12:06

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#14 2011-06-20 07:44:23

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#15 2011-06-20 07:56:02

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#16 2011-06-20 08:03:00

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#17 2011-06-20 08:20:18

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#18 2011-06-20 08:26:02

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#19 2011-06-20 09:56:33

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#20 2011-06-20 10:07:42

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#21 2011-06-20 11:42:26

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#22 2011-06-20 11:51:18

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#23 2011-06-20 11:55:39

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#24 2011-06-20 11:59:37

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

#25 2011-06-20 12:04:08

Re: Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

Board footer