Wenn man konsequent wäre, müsste es wie bei den oberbayrischen Seen das Wasser einschließen. Da es da aber keine optischen Löcher gibt, tendiere ich auch dahin, dem Postboten trockene Füße zu lassen.
Die Grenzen auf Wasser sind eine für Landratten komplizierte Geschichte, da sollten sich die Küstenbewohner drum kümmern.
Übrigens: Die Landmasse-Relationen haben oft AGS und RGS spendiert bekommen, zusätzlich zu den admin-Relationen. Die werden bei MisterBoo angemeckert. Scheint mir ein ähnliches Duplikat-Problem zu sein.
Die Problematik zeigt sich z.B. auch am Restaurant auf der Seebrücke Sellin, das ja eindeutig eine PLZ für seine Adresse hat - aber (wenn auch nicht komplett) außerhalb der Landmasse liegt.
Die Problematik “(Gemeinde-)Grenze an Küste” ist leider nicht so ganz einfach (Folgendes stark vereinfacht):
Früher galt “Gemeindegebiet geht bis Wasserlinie”.
Für Seebrücken u. ä. gab es dann so ein Konstrukt “schwebend über hoheitlichem Grund”.
Dann gibt es moderne Gerichtsurteile, nach denen manche Wasserflächen (insbesondere Marina-Gebiete) zum Gemeindegebiet gehören (Stichwort Steuern/Kurabgaben/Ausbaubeiträge etc.)
Die OSM-Gemeinde-Grenzen in Schleswig-Holstein sind deshalb damals nach den im Laufe des Mapping-Prozess veränderten Erkenntnissen provisorisch größtenteils aufs Wasser gelegt worden - und bis heute nicht eindeutig geklärt.
Finde ich auch richtig, dass sie AGS und RGS haben. Wie soll man sie sonst identifizieren/zuordnen? Durch type=land_area sind sie doch klar von type=boundary zu unterscheiden.
Ich habe mir mal die Zahlen angeschaut. Wir haben in Deutschland inzwischen nur noch 325 Gemeinden, die nicht als boundary, sondern als multipolygon getypt sind. All diese Gemeinden befinden sich übrigens in Schleswig-Holstein oder Bayern.
Daher kann von Massenumtaggen eh keine Rede sein. Wir Reden hier eher von Exoten. Und die genießen für mich in Datenbanken keine Minderheitenschutzrechte.
Da wir eh da noch “vorbeikommen”, ist das jetzt nicht so schlimm. Genauso die type=multipolygon in SH.
Eigentlich wollte ich nur sagen, dass der Nordwesten nicht ganz so langweilig ist wie der Südwesten. Da unten hat seichter so gute Vorarbeit geleistet, dass es richtig langweilig ist, die PLZ-Boundaries zu erstellen - kopieren, Tags löschen, Admin-Rel anpassen, feddich, die nächste bitte, …
Ich will mich nicht mit fremden Federn schmücken: (fast) alle PLZ-Tags habe ich aus den Vorgängerrelationen übernommen. Ich habe mir den Osten (Württemberg) vorgenommen, auch wenn ich die Notwendigkeit bei 1:1-Relationen immer noch so ganz einsehe (JOSM meckert auch wegen identischer Mitglieder). Aber wie war das mit dem fehlenden Altersstarrsinn?
Ich war da gestern abend zugange, kümmere mich darum. Ich habe versucht, sicherzustellen, dass alle Relationen wieder geschlossen sind, kann aber ein paar PLZ-Rels übersehen haben.
Bin ab heute wieder daheim und kann auf dem großen Rechner arbeiten, wo ich mehr Werkzeuge und Kontrollmöglichkeiten habe.
Bei den neuen Grenzen gibt es ein paar Enklaven mehr, bei denen ich den “Eigentümer” noch nachsehen muss, aus Maps4BW ließ er sich nicht ersehen.
Die Sache ist gestern Abend passiert und zu der Zeit betrug der Lag meiner PLZ-Karte bis zu vier Stunden Da sind am Nachmittag wohl wieder einige “Weekend”-Uploads eingetrudelt, die den DIFF-Update erheblich verzögert haben. War letzten Sonntag genau so.
Und aus dem Grund wurden die Probleme auf meiner Live-Karte erst sehr spät angezeigt. Heute morgen fiel es mir dann natürlich auf.
Der Peek am linken Rand (Samstag nachts) wurde durch eine planmäßige Wartung meinerseits verursacht. Hat sich auch nicht viel angesammelt und wurde in ca 30 Minuten abgebaut.
Als ich mich vorhin im Deutsch-Belgischen Grenzgebiet “verlaufen” hatte, hab ich festgestellt, daß es zumindest einen fleißigen Mapper dort gibt, die die belgischen PLZ-Gebiete nach unserem Schema erfaßt. Hier mal eine Karte vom 17.12 ca 2:00 Uhr:
It’s a pleasant surprise to see that our work was noticed here as well
I was tired of seeing Nominatim results with the wrong postal code. I remembered seeing postal code boundaries mentioned in the Nominatim FAQ as well as on this forum. (I can read German more or less, but won’t try to write in it)
I gave it a try, and saw that my Nominatim problem was gone. The main problem was that Nominatim uses the nearest (imported) postal code node. I mentioned this on the Belgian mailing list and even gave a Google Hangout presentation last Friday about it. Although the main topic was mapping the admin_level 9 boundaries which are usually the building blocks for the postal code areas in Belgium.
While I did most of the areas shown in the above picture, a few others contributed around Leuven, Gent (Ghent) and Antwerpen (Antwerp).
I’ll expect to see more postal_code areas being mapped in the coming weeks.
I used the schema I found near Bochum, so I also add a note = .
Wir haben gestern 58300 Wetter (Ruhr) verloren [Ist jetzt wieder da]. Ich kontrolliere täglich die Diffs unserer PLZ-Liste und sehe das dann. Ich frage mich nur, wie wir das systematischer machen können, um unbemerkte Unfälle zu verhindern oder schon die Unfälle selbst zu vermeiden. Eine doppelte PLZ fällt noch auf (hier war es dann 45549). Bei einer falschen PLZ (z.B. Zahlendreher) wird es schon schwieriger. Für die QS kommt man wohl um eine Referenzliste nicht herum. Wenn wir uns die nicht von der Post kaufen (und dann lange über die Nutzungsbedingungen diskutieren), müssten wir eine Liste aus einem OSM-Zustand zur Referenz erklären und bei Änderungen (vierteljährlich) anpassen. Das birgt natürlich auch Tücken. Ich habe erst vor wenigen Tagen eine falsche PLZ zufällig entdeckt (Zahlendreher).
Dann werde ich mich mal auf NRW stürzen.
Da sind am Nachmittag wohl wieder einige “Weekend”-Uploads eingetrudelt, die den DIFF-Update erheblich verzögert haben. War letzten Sonntag genau so.
