Eine Sache ist mir durch die aktuelle Version aufgefallen.
Oft werden die Admin-Grenzen mit den Postleitzahlen gleich gesetzt. Das ist im allgemeinen recht praktisch. Wenn es jedoch En-/Exklaven gibt, dann werden disjunkte Gebiet mit der gleichen Postleitzahl versehen. Das ist auf dem Lande recht häufig. Ich weiß nicht, ob die Post bei den PLZ solche En-/Exklaven berücksichtigt, glaube es jedoch nicht.
Auf diesem Ausschnitt entlang der Lahn besteht kaum ein PLZ-Gebiet aus einer geschlossen Fläche. Singhofen (56379) und Schönborn (56370) sind gute Beispiele dafür.
Es wäre schön, wenn man die für den händischen Import verwendeten PLZ-Grenzen noch als weiteren Layer haben könnte. So könnte man vergleichen, ob geteilte PLZ-Gebiete auch ursprünglich geteilt waren.
Die in Import/Catalogue/Postleitzahlen_Deutschland_2010 erwähnten Dienste der Geofabrik funktionieren (soweit ich das sehen kann) zur Zeit leider nicht. (Frederik, falls du mitliest, kann man die ggfs. wieder reaktivieren?)
Der bei den PLZ-Grenzen erwähnte WMS-Service antwortet zumindest.
Ich hab mal ein wenig “gespickt”: Ja, sie tut es. Singhofen und Schönborn sind ok - also berücksichtigt die Post solche wohl historisch gewachsenen Strukturen.
nun ja, ich nehme es mal auf obwohl ich die Hoffnung hatte, dass langsam mal Schluß ist. → todo
Der Junge stellt auch die Rohdaten als Shapes zur Verfügung. Also werde ich mir die besorgen und wohl meinen kleinen WMS-Server anschmeissen Kann aber etwas dauern (Ubuntu läuft schon drauf)
Gruss
walter
p.s. zur Zeit bekommt der Residential-Map das Admin-Borders Level.
Hmmh, bei mir steht in Import/Catalogue/Postleitzahlen_Deutschland_2010 folgendes:
- http://tools.geofabrik.de/osmi/view/plz/wxs?REQUEST=GetMap&SERVICE=wms&VERSION=1.1.1&FORMAT=image/png&SRS=EPSG:4326&STYLES=&LAYERS=plz_source,plz_osm&
Du hast hingegen angegeben:
- http://tools.geofabrik.de/osmi/views/plz/wxs?FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=plz_source&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
Deine Variante liefert zumindest eine Antwort, die aus der Wiki-Seite liefert nur einen Server-Error. Die beiden Angabe unterscheiden sich a) in Details (WMS statt wms, *.jpg statt *.png) und b) ab LAYERS=plz_source.
Nachtrag:
Habe es jetzt mal in JOSM ausprobiert. Die Variante auf der Webseite muss im Dialog für einen neuen WMS-Server bei Punkt 1 “Dienst-Url” eingegeben und dann die gewünschte Ebene ausgewählt werden. Das ergibt dann deine Variante für die PLZ-Quelle.
Hinweis: Die PLZ-Quelle hat generell einen Versatz Richtung Nord-Ost gegenüber der Realität. Die PLZ-Ebene sollte man daher anhand von eigenen Kenntnisse entsprechen verschieben. Leider ist der Versatz nicht einheitlich und die PLZ-Quelle berücksichtigt Änderungen wie Neubaugebiete der letzten 24 Jahre nicht.
Ich sollte mal ein paar Worte zu den gerade gefundenen Lösungen auf der Wiki-Seite ergänzen. Auf diese Probleme müssen ja nicht noch mehr Mapper reinfallen.
Klar, Josm kann mit jedem WMS und TMS was anfangen - wieder einer der Punkte, weswegen ich Josm so schätze
Aber in der PLZ-Karte kommt es auf Vergleichsmöglichkeiten an: Alt gegen Neu, Ist gegen Soll, Adressen gegen PLZ-Gebiete und sowas. Da hilft dir Josm auch nicht viel weiter.
Immerhin haben wir auf diesem Weg eine funktionierende Quelle für die Originale gefunden. Problem ist, dass diese Ebene verschiebbar sein müsste, um den vorhandenen Versatz ausgleichen zu können. Gegen Änderungen durch z.B. Neubaugebiete kann das natürlich nicht helfen.
Wie gesagt, als Vergleich, was zusammen war und was nicht, wäre das nach meiner Meinung nützlich.
Die Datenmengen dürften eher gering sein, da es nur wenige Striche und Zahlen gibt.
Wenn ich das so genau wüsste.
Es scheint sich um einen systematischen Fehler bei der Konvertierung zu handeln. Das heißt, dass es keine Sprünge im Versatz gibt, aber über etliche Kiolmeter doch kleinere Änderungen (so habe ich das bisher gesehen).
Zur Größenordnung kann ich sagen, dass bei eingestellten Versatz für Bonn (ca. Mitte Rhein) in Koblenz (ca. 60km südöstlich) die PLZ-Quelle die Grenze auf der linken Rheinseite hat.
Vielleicht weiß jemand in der Mailingliste noch, woran dieser Versatz lag und ob/wie man ihn beheben kann.
Ich hoffe, das läuft nicht auf eine komplexe Koordinatentransformation hinaus - eines der wenigen Dinge bei OSM, die mir wirklich nicht liegen. Lieber tagge ich HKTS
Die “Alten PLZ-Grenzen” sind seit gestern als WMS-Layer in der aktuellen Version 2.08 drin. Ich mußte heute nur noch checken, ob meine Firewall Requests auf Port 81 durchläßt - tut sie Daher das verspätete Announcement.
Ich habe die Layer-Daten nicht verschoben, da ich keine generelle “Richtung” erkennen konnte und mir auch nicht klar ist, wie ich das machen sollte. Der Feedback dazu war äußerst dürftig. (=0)
Die Daten kommen (noch) nicht von meinem Cubie-Server (*). Mapserver unter Ubuntu 13.04 läuft zwar drauf - sogar ziemlich flott - allerdings ist der Micro-Rechner noch nicht über das Internet erreichbar.
Danke dafür.
In Bonn als Beispiel sind die “Alten PLZ-Grenzen” offensichtlich nur nach Westen verschoben worden. Dabei wurden sie wohl am Rhein als natürlichem Hinderniss (nur drei Brücken) ausgerichtet. Die kleinere Korrektur Richtung Süden wurde mangels solch offensichtlichen Grenzen wie Flüssen offensichtlich nicht erkannt.
Die Post orientiert sich bei den PLZ-Grenzen offensichtlich gerne an natürlichen (z.B. Flüsse) oder künstlichen (Eisenbahnen, Autobahnen, große Straßen, …) Hindernissen. Das gilt allerdings nur für größere Städte, auf dem Land
Dass du die “Alten PLZ-Grenzen” nicht verschoben hast, kann ich gut nachvollziehen, da dabei kein einheitliches Muster zu erkennen ist.
PS-1: Die Suche scheint zur Zeit nicht zu funktionieren.
PS-2: Bei der Flächen-Hervorhebung (ein sehr nützliches Detail)
erscheinen Teile der Grenzen in grün, andere bleiben gelb.
Was ist die Ursache dafür?
Suche geht wieder: Es gab bei einer dringend notwendig gewordenen Aufräumaktion am Sonntag wohl kleinere “Kolateralschäden”
und die PLZ-Flächen sehen jetzt wohl ohne Kante besser aus. (1 x Reload im Browser machen oder 2 Stunden warten)
Der Grund ist mir inzwischen klar und das erschien mir als die einfachste Lösung.
Da mir das auch bei der ORM mit einem kleinen Unterschied zur bisherigen Beschreibung aufgefallen ist: Woher kommen die Graustufen-Kacheln? Werden da die normalen ihrer Farben beraubt? Bei der ORM scheint mir das so zu sein und dort sieht man nur die jeweilige Farb-Variante, nicht die anderen beiden (was bei der OSMPC-Karte mangels weiteren Layern nicht sichtbar war).
Nachdem das Raid5 endlich wieder rennt, ist die PLZ-Karte wieder online.
Allerdings wird es noch einige Tage dauern bis das Lag von 26 Tagen !!! abgebaut ist. Der Lag steht ja am unteren Ende der Karte und wird minütlich aktualisiert. Ein Klick auf den Link zeigt eine kleine Grafik.
Datenverluste gab es übrigens nicht, nur das Raid hat sich “ein wenig geziert”.
Warum sollten Gemeinde-Relationen nicht mit “postal_code” markiert werden? Ich sehe das anders. Eine Unterscheidung zu den “echten” PLZ-Gebieten kann auch über “postal_code_level” erfolgen.
Ist eine Gemeinde nicht identisch mit dem PLZ-Gebiet, sollte “postal_code_level=8” nicht gesetzt sein. Andernfalls würde ich die Kombi mit “postal_code” erlauben. Langfristig sollte es wohl für alle PLZ dedizierte Relationen geben. Aber auch dann ist es nicht notwendig, den “postal_code” bei Gemeinden zu löschen.
Laut Post gibt es in DE 8208 Zustellgebiete.
Status quo der PLZ in OSM (20.10.2013):
Es gibt 6043 dedizierte postal_code-Relationen. 5 sind nicht eineindeutig (PLZ: 38486, 15236, 22113, 16835, 18249)
Es gibt für davon nicht erfasste PLZ 1095 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1069 Gemeinden, für die keine PLZ-Relation gegeben und kein postal_code_level getaggt sind, die aber einen postal_code haben.
Davon sind 14 PLZ nicht eindeutig (2 Gemeinden mit gleicher PLZ).
Insgesamt sind 8188 PLZ erfasst. Fehlen noch 20 PLZ.
tja, da gibt es wohl derzeit verschiedene Auffassungen:
Meiner Meinung nach sollte in den OSM-Daten eine Grenzrelation (egal ob postal_code oder admin) zu einer bestimmten PLZ nur ein einziges Mal vorkommen.
Wenn neben einer postal_code Relation nun auch noch eine administrative Relation die gleiche PLZ enthält, so ist es in meinen Augen eine redundante Datendoppelung.
Denn wenn man argumentieren wollte, dass an die admin_Relationen die PLZ-Werte zusätzlich enthalten sein sollen (wegen Zuordnung Gemeinde → PLZ) dann müsste ja an JEDE admin-Relation die entsprechende PLZ! Hmmm …
Und wenn die admin-Relation kleiner ist als die PLZ-Relation? … oder gar GRÖßER , d.h. eine Gemeinde hat mehrere PLZ … dann mit Semikolon trennen???
Kann aber etwas dauern (Ubuntu läuft schon drauf)
