Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

wambacher · 2013-11-12 11:29:13

EvanE wrote:

In dem Fall meinte ich statt name=<PLZ><Ort> besser bei note=<PLZ><Ort> bleiben.
Die PLZ-Relationen sollten besser von den Admin-Relationen getrennt werden.
Die Wege kann man ja dort, wo sie gemeinsam sind, in beiden Relationen benutzen.

jetzt sind wir schon drei

Die Anzeige-Reihenfolge für Relationen-Bezeichnungen sind eine Liste von Schlüsseln, die man auch lokal ergänzen oder ändern kann. Es wäre also kein große Sache, einen neuen Schlüssel für die Relationen-Bezeichnungen standardmäßig in JOSM zu integrieren.

Wieder eines der kleinen Josm-Geheimnisse.

wambacher wrote:
ps: hast du schon eine Meinung zu Nominatim? Ich bin mir derzeit noch unsicher.
In welcher Hinsicht? PLZ-Gebiete findet er offensichtlich über die ref-Angabe.

ref? die haben wir doch garnicht drin, oder? Ansonsten hab ich mal ein wenig getestet. Er benutzt -natürlich- die plz aus der plz-relation und damit sollte alles ok sein.

Ob Nominatim Stimmbezirke finden soll, da habe ich mir noch keine Meinung gebildet.

warum nicht, wenn der als boundary mit seinem passenden boundary=* drin ist. Eventuell kann man das bei der Suche (als Anwender) filtern?

Gruss
walter

seichter · 2013-11-12 11:38:32

EvanE wrote:

Ich habe an norender_name oder an virtual_name gedacht. Der konkrete Name des Schlüssels ist mir unwichtig. Er sollte nur in möglichst vielen Fällen nutzbar sein.

Gut, wenn label schon anderweitig belegt ist (ich wollte neue Schlüssel nur einführen, wenn unvermeidbar), dann ein neuer Schlüssel. Da tendiere ich bei so einer grundsätzlichen Funktion (ich bin keine echte Geo-Information) auch eher zu etwas auf oberster Stufe wie identifier. Das stünde dann auf gleicher Stufe wie label oder note. Ob es identifier heißt, wäre wäre mir nicht so wichtig, Hauptsache ein griffiger und selbsterklärender Begriff.

Als Zwischenlösung, solange <identifier> noch ignoriert wird, würde ich parallel dazu bei note bleiben, mit dem Vermerk, dass diese (unerwünschte) Verwendung aufgegeben wird, sobald <identifier> auf breiter Basis für Darstellungen, Anzeigen etc. ausgewertet wird.

wambacher · 2013-11-12 11:39:06

Gehrke wrote:

wambacher wrote:
Was ist mit Nominatim? Bekommt der - und damit wir - Probleme?
Ich habe leider keine Ahnung von Nominatim. Aber wenn man sich anschaut, welche PLZ-Informationen bisher anscheinend genutzt wurden (places und admins?), glaube ich nicht, dass eine Umstellung auf postal_code-Relationen für Nominatim ein Rückschritt wäre.

Er nimmt definitiv auch die PLZ-Boundary zur Suche. Wenn ich in openstreetmap.org nach "65388" suche (PLZ von Schlangenbad) hat er als 2. Treffer die PLZ-Relation http://www.openstreetmap.org/browse/relation/3320567 und auf nomination.openstretmap.org zeigt er die auch sauber an: http://nominatim.openstreetmap.org/deta … 9149874830
Scheint also alles in Butter zu sein.

Dann ist mir auch (fast) egal, ob ein postal_code an der admin-Relation ist. Wenn das aber so ist, wäre ich dafür, einheitlich die eine PLZ aus den DESTATIS-Daten für die Gemeindeverwaltung zu nehmen. Das hieße dann z.B. "postal_code=28195" für Bremen und "postal_code=80331" für München. Oder bringt das dann Nominatim durcheinander? Experten hier?

Ist das die PLZ der Gemeindeverwaltung? Sollte wohl kein Problem machen.

Gruss
walter

wambacher · 2013-11-12 11:40:55

seichter wrote:

EvanE wrote:
Wir sollten allerdings mal einen Schritt zurücktreten und bemerken dann, dass generell ein Namens-Problem bei boundary-Relation besteht (siehe die Diskussionen zu Stimmbezirken).
Ich denke, an diesem Beispiel sind wir an tatsächlich an ein grundsätzliches Problem gestoßen.
Es gibt in OSM echte ortsbezogene Daten (das kann ein Name, aber auch ein Jahreszahl für ein Ereignis an diesem Ort sein) und andere, ich nenne sie mal Metadaten. Dazu gehören die eindeutigen Objekt-IDs, ohne die keine DB funktionieren kann, aber auch Einträge, um Relationen z.B. im Editor besser identifizieren zu können. So ist ja wohl der note-Eintrag in PLZ-Relationen entstanden.
Wir taggen nicht für den Auswerter sollte ja mMn im Kern bedeuten, dass man nicht echte Geo-Informationen manipuliert, um bestimmte Darstellungen zu erzeugen. Wir taggen aber auch nicht gegen den Auswerter, sollten ihm die Arbeit im Gegenteil so gut es geht erleichtern. Sollte man da nicht Nägel mit Köpfen machen und diese Meta-Informationen ehrlich deklarieren? Der note-Tag ist so ein Fall: Er richtet sich nur an andere Tagger und ist keine eigentliche Geo-Information. Kann man nicht einen Tag finden, der ausdrücklich nur für interne Zwecke vorgesehen ist und gezielt ignoriert oder z.B. im Editor gezielt verwendet werden kann? Als Kandidat fällt mir da "label" ein, "ref" sagt mir nicht so zu, da es in vielen Fällen (Straßennummern) eine echte Geo-Information ist.
Bleibt "nur" noch das Problem, dass die Auswerter das für sie gedachte Tag auch verwenden. Die Aussicht, damit endlich mal echte von unechten Geo-Informationen zu trennen, scheint mir die Mühe
Ein ähnlich gelagertes Problen hat man auch, wenn man dem Renderer eine geeignete Stelle für die Plazierung eines Namens vorschlagen will. Da ist ja das place-Tag leicht zweckentfremdet worden (das ja als place=locality eindeutig eine Geo-Bedeutung hat).

Ich finde, dieser Aspekt ist einen eigenen Thread wert, sonst geht der hier unter. Besonders die gerade startende Grundsatzdebatte "Wohin mit den Rel-Tags und wenn ja, welche?" könnte dort geführt werden.

Gruss
walter

Last edited by wambacher (2013-11-12 11:46:39)

EvanE · 2013-11-12 15:02:08

wambacher wrote:

EvanE wrote:
Die Anzeige-Reihenfolge für Relationen-Bezeichnungen sind eine Liste von Schlüsseln, die man auch lokal ergänzen oder ändern kann. Es wäre also kein große Sache, einen neuen Schlüssel für die Relationen-Bezeichnungen standardmäßig in JOSM zu integrieren.
Wieder eines der kleinen Josm-Geheimnisse.

Hallo Walter

Da bin ich zufällig drüber gestolpert, als ich etwas ganz anderes suchte. Als ich das sah, machte es Klick bei mir. Das war doch ein Teilproblem bei den Stimmbezirken, die in der Relationenliste leicht von anderen Grenzen unterscheiden zu können.

Vielleicht hat jemand einen Tipp für mich, wie ich mein ursprüngliches Problem lösen kann. Es geht darum den Platz für die Objektanzeige in der Infoleiste ganz unten zu vergrößern. In all den hunderten einstellbaren Werten habe ich nichts gefunden, was nur im entferntesten passend klang.

Edbert (EvanE)

EvanE · 2013-11-12 15:11:02

wambacher wrote:

EvanE wrote:
wambacher wrote:
ps: hast du schon eine Meinung zu Nominatim? Ich bin mir derzeit noch unsicher.
In welcher Hinsicht? PLZ-Gebiete findet er offensichtlich über die ref-Angabe.
ref? die haben wir doch garnicht drin, oder? Ansonsten hab ich mal ein wenig getestet. Er benutzt -natürlich- die plz aus der plz-relation und damit sollte alles ok sein.

Hallo Walter

Bei den reinen PLZ-Relationen hier in Bonn ist die PLZ zusätzlich als ref=* eingetragen.
("reine PLZ-Rel." im Sinne von ohne Verquickung mit Admin-Grenzen)

Edbert (EvanE)

Gehrke · 2013-11-13 09:50:30

Status quo der deutschen PLZ in OSM (12.11.2013, ca. 21:00 Uhr):
Es gibt 6128 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1075 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1005 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8207 PLZ erfasst. Fehlte also eigentlich nur noch eine PLZ, wenn denn keine falschen dabei wären!
Lücken bestehen noch in Düsseldorf. Dort fehlen 17 PLZ-Gebiete: 40210, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40591.

Ergo: Keine Änderung zu gestern (habe allerdings heute bereits 2 ungültige PLZ aufgespührt und korrigiert: 01827 Graupa und 02744 Oberoderwitz)

Athemis · 2013-11-13 20:30:26

Hallo zusammen,

Gehrke wrote:

Lücken bestehen noch in Düsseldorf. Dort fehlen 17 PLZ-Gebiete: 40210, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40591.

ich habe mich mal der 40591 angenommen . Bei der Gelegenheit sind direkt noch ein paar Adressen mit falscher PLZ auf meine TODO-Liste gewandert...

Alex (Athemis)

Last edited by Athemis (2013-11-13 21:03:49)

Gehrke · 2013-11-14 09:11:00

Status quo der deutschen PLZ in OSM (13.11.2013, ca. 21:00 Uhr):
Es gibt 6130 dedizierte postal_code-Relationen.
Für davon nicht erfasste PLZ gibt es 1072 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1005 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8207 PLZ erfasst. Fehlte also eigentlich nur noch eine PLZ, wenn denn keine falschen dabei wären!
Lücken bestehen noch in Düsseldorf. Dort fehlen 15 PLZ-Gebiete: 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239.

@Athemis: Vielen Dank für 40591 Düsseldorf!

Ich werde mich der PLZ 40212, 40213 und später 40215 annehmen.

Last edited by Gehrke (2013-11-14 09:11:51)

wambacher · 2013-11-14 12:37:58

Ich hab mal versucht, die Sache mit QGIS zu visualisieren:

groß: http://osm.wno-edv-service.de:8080/Data … erlay1.png

groß: http://osm.wno-edv-service.de:8080/Data … rlay2n.png

groß: http://osm.wno-edv-service.de:8080/Data … rlay2s.png

Gelb: PLZ an boundary=postal_code
Blau: PLZ an boundary=administrative
Grün: beides

an manchen Stellen "schimmert" OSM durch; da ist nichts erfasst oder es liegt ein MP-Fehler von. (z.B. bei Grünstadt/Pfalz war das MP defekt, ist aber inzwischen erledigt und die Lücken in Düsseldorf und im Bayrischen Wald bestehen weiterhin)

Ich werde wohl in meiner PLZ-Karte entsprechende Anpassungen machen, falls Interesse daran besteht.

Gruss
Walter

Last edited by wambacher (2013-11-22 13:45:56)

Gehrke · 2013-11-14 13:46:05

wambacher wrote:

Ich hab mal versucht, die Sache mit QGIS zu visualisieren: [...]

Vielen Dank, Walter!

Die gestern zerstörten Grenzen bei Luxemburg (PLZ 54441) habe ich heute morgen gefixt.

In Bayern sind drei Seen gemeindefrei. Für eine volle Abdeckung (auch im Hinblick auf eine PLZ-Regionenkarte) müsste man die einer Region zuschlagen. Die Post macht das in ihrer Karte auch so.

JohnDoe23 · 2013-11-14 16:27:48

wambacher wrote:

und die Lücken in Düsseldorf und im Bayrischen Wald bestehen weiterhin)

Wie ist das bei gemeindefreien Gebieten (Bayerischer Wald), tragen die überhaupt eine PLZ? Bzw. wie kann man die PLZ herausfinden, diese Gebiete sind ja meist unbewohnt, gibt es andere Quellen?

Die PLZ von Mauther Forst (gemeindefrei) wurde in OSM z.B. Freyung zugeschlagen, trotz räumlicher Trennung. Existiert eventuell ein festes Vergabesystem seitens der Post oder ist das willkürlich?

Gruß JohnDoe

Gehrke · 2013-11-14 17:07:03

JohnDoe23 wrote:

Wie ist das bei gemeindefreien Gebieten (Bayerischer Wald), tragen die überhaupt eine PLZ?

Gemeindefreie Gebiete haben keine PLZ (wenn dort niemand wohnt). Eine PLZ gilt ja für Häuser und keine Gebiete.
Die postalische Gebietseinteilung ist zu einem gewissen Grad künstlich. Das gilt nicht nur für gemeindefreie Gebiete,
in denen niemand wohnt, sondern eigentlich auch für einen unbewohnten Forst o.ä., der Teil einer Gemeinde ist.

Für ihre Postleitzahlenkarte schlägt die Post gemeindefreie Gebiete mehr oder weniger willkürlich einem anderen PLZ-Gebiet zu.
In OSM ist das nmM bisher oft besser/sinnvoller gelöst.

Ich bin für eine lückenlose Partionierung des Bundesgebietes in PLZ-Grenzen - also auch gemeindefreie Gebiete.
Ein Grund hierfür sind auch die Postleitregionen (z.B. 28 für 28359) bzw. Postleitzonen (2). Es wäre ja unintuitiv
dort für jede unbewohnte Ecke einen weißen Fleck (als Enklave) zu haben.

Last edited by Gehrke (2013-11-14 17:34:22)

wambacher · 2013-11-14 17:55:05

so ganz unbewohnt ist die Exklave im bayrischen Wald ja nicht. Ich würd da einfach mal anrufen und nachfragen.

Gruss
walter

Gehrke · 2013-11-14 18:05:34

wambacher wrote:

so ganz unbewohnt ist die Exklave im bayrischen Wald ja nicht. Ich würd da einfach mal anrufen und nachfragen.

Die Ecke hatte ich ganz übersehen. Da es eine Exklave von Philippsreut ist (und auch gleich daneben), wird es sehr sicher die PLZ 94158 haben. (bestätigt für die die dortige Almbergstraße)
Ich werde das ganze Waldgebiet daher mal der PLZ-Relation für 94158 zuschlagen.

Gehrke · 2013-11-14 18:16:25

Gehrke wrote:

wambacher wrote:
so ganz unbewohnt ist die Exklave im bayrischen Wald ja nicht. Ich würd da einfach mal anrufen und nachfragen.
Die Ecke hatte ich ganz übersehen. Da es eine Exklave von Philippsreut ist (und auch gleich daneben), wird es sehr sicher die PLZ 94158 haben. (bestätigt für die die dortige Almbergstraße)
Ich werde das ganze Waldgebiet daher mal der PLZ-Relation für 94158 zuschlagen.

Habs mir anders überlegt. Der Annathaler Wald gehört logisch doch wohl er zu Annathal. Ich füge erstmal nur die Exklave hinzu.

Gehrke · 2013-11-14 18:30:50

JohnDoe23 wrote:

Die PLZ von Mauther Forst (gemeindefrei) wurde in OSM z.B. Freyung zugeschlagen, trotz räumlicher Trennung.

Das war keine gute Wahl. Der Wald enthält sogar Häuser mit Mauther PLZ. habe das korrigiert.

JohnDoe23 · 2013-11-14 18:44:15

Gehrke wrote:

JohnDoe23 wrote:
Die PLZ von Mauther Forst (gemeindefrei) wurde in OSM z.B. Freyung zugeschlagen, trotz räumlicher Trennung.
Das war keine gute Wahl. Der Wald enthält sogar Häuser mit Mauther PLZ. habe das korrigiert.

Ok, das könnte dann auf den Schönbrunner Wald eventuell auch zutreffen, der trägt bis jetzt auch noch die PLZ von Freyung, obwohl räumlich getrennt, liegt gleich neben dem Mauther Forst. Könnte eventuell zur Gemeinde Hohenau gehören (Orte namens Schönbrunn am Lusen und Schönbrunnerhäuser in dieser Gemeinde)

Ansonsten:
Sollte man dann den Schlichtenberger Wald der PLZ der Gemeinde Hinterschmiding zuteilen (In der Gemeinde liegt ein Ort namens Schlichtenberg) und den Philippsreuter Wald zur Gemeinde Philippsreut?

Dann gäbe es soweit keine gemeindefreien Gebiete ohne PLZ im Landkreis Freyung-Grafenau.

wambacher · 2013-11-14 23:13:06

wambacher wrote:

Ich werde wohl in meiner PLZ-Karte entsprechende Anpassungen machen, falls Interesse daran besteht.

Nachdem ich von Wünschen, dieses Feature einzubauen, glatt erschlagen wurde, ist es in der aktuellen Version 3.1 drin

Ab sofort werden die PLZ-Gebiete getrennt dargestellt, je nachdem woher die Info stammt.

Das Layer "Postal Borders" zeigt in gelb die Gebiete an, die mit boundary=postal_code getaggt wurden.
"Postal Borders (admin)" dagegen die administratinen Grenzen (Gemeinden), die zusätzlich einen postal_code enthalten. Diese in Rot, da bei überlappenden Gebieten - also da wo beide Grenzen erfaßt wurden - ein Orange wird.

Es gibt auch Stellen, wo sich beide Grenzen widersprechen, d.h. je nach "Grenzwahl" kommt ein anderes Ergebnis raus. Das zu visualisieren, werde ich morgen mal versuchen.

Wie schon mehrfach diskutiert, möchte ich erreichen, daß
- redundante Informationen gelöscht werden (postal_code aus der Administrativen Grenze raus)
- eine neue Postal Boundary erstellt und von der Admin-Boundary entkoppelt wird.

sodaß am Ende postalische Informationen nur noch in den PLZ-Boundaries stehen - ausgenommen natürlich die Hausadressen, die damit nicht zu tun haben.

Gruß
walter

wambacher · 2013-11-15 01:26:32

EvanE wrote:

Bei den reinen PLZ-Relationen hier in Bonn ist die PLZ zusätzlich als ref=* eingetragen.
("reine PLZ-Rel." im Sinne von ohne Verquickung mit Admin-Grenzen)

Ich glaube, du musst das inzwischen geändert haben; zumindest finde ich keine einzige bei uns mit ref:

 osm_id  |  boundary   | postal_code | name | note | description | ref  |   country    |                         api                 
---------+-------------+-------------+------+------+-------------+------+--------------+------------------------------------------------------
 1106845 | postal_code | 7708        |      |      |             | 7708 | South Africa | http://www.openstreetmap.org/browse/relation/1106845
 2035208 | postal_code | 7806        |      |      |             | 7806 | South Africa | http://www.openstreetmap.org/browse/relation/2035208
(2 rows)

Gruss
walter

Gehrke · 2013-11-15 09:32:49

wambacher wrote:

Ab sofort werden die PLZ-Gebiete getrennt dargestellt, je nachdem woher die Info stammt.

Mich irritiert ein bisschen die Lücke zwischen benachbarten Areas. Ist das Absicht?
Dachte zuerst, wo ich guckte, sei etwas kaputt.

Grüße
Jan

Gehrke · 2013-11-15 11:05:41

Status quo der deutschen PLZ in OSM (14.11.2013, ca. 21:00 Uhr):
Es gibt 6138 dedizierte postal_code-Relationen.
Für davon nicht erfasste PLZ gibt es 1067 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1004 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Insgesamt sind 8209 PLZ erfasst. Lücken bestehen noch in Düsseldorf. Dort fehlen 13 PLZ-Gebiete: 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40231, 40233, 40235, 40237, 40239.
Wir kommen damit dann auf 8222 PLZ. Laut Post gibt es in DE aber nur 8208 Zustellgebiete. Somit gibt es mind. 14 falsche, veraltete PLZ.

Gehrke · 2013-11-15 12:54:18

JohnDoe23 wrote:

Sollte man dann den Schlichtenberger Wald der PLZ der Gemeinde Hinterschmiding zuteilen (In der Gemeinde liegt ein Ort namens Schlichtenberg) und den Philippsreuter Wald zur Gemeinde Philippsreut?
Dann gäbe es soweit keine gemeindefreien Gebiete ohne PLZ im Landkreis Freyung-Grafenau.

Done.

seichter · 2013-11-15 14:03:06

Gehrke wrote:

Mich irritiert ein bisschen die Lücke zwischen benachbarten Areas. Ist das Absicht?
Dachte zuerst, wo ich guckte, sei etwas kaputt.

Finde ich ok - dadurch liegen bei höheren Zoom-Stufen die Linien der Layer nicht übereinander.
Der postal_code_level wird übrigens auch ausgewertet (steht weiter oben auch implizit).

stephan75 · 2013-11-15 14:41:42

Hallo an alle Beteiligten,

wie wäre es, wenn wir für die Umwandlung / Erweiterung auf reine PLZ-Relationen in Deutschland einen extra Thread aufmachen würden?

Den dieser hier ist schon fast zu lang, und es hat sich ein eigenständiges Thema gebildet.

Announcement

#176 2013-11-12 11:29:13

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#177 2013-11-12 11:38:32

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#178 2013-11-12 11:39:06

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#179 2013-11-12 11:40:55

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#180 2013-11-12 15:02:08

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#181 2013-11-12 15:11:02

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#182 2013-11-13 09:50:30

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#183 2013-11-13 20:30:26

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#184 2013-11-14 09:11:00

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#185 2013-11-14 12:37:58

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#186 2013-11-14 13:46:05

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#187 2013-11-14 16:27:48

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#188 2013-11-14 17:07:03

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#189 2013-11-14 17:55:05

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#190 2013-11-14 18:05:34

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#191 2013-11-14 18:16:25

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#192 2013-11-14 18:30:50

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#193 2013-11-14 18:44:15

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#194 2013-11-14 23:13:06

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#195 2013-11-15 01:26:32

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#196 2013-11-15 09:32:49

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#197 2013-11-15 11:05:41

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#198 2013-11-15 12:54:18

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#199 2013-11-15 14:03:06

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

#200 2013-11-15 14:41:42

Re: Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

Board footer