Import/Catalogue/Postleitzahlen Deutschland 2010
Arbeitsplan
Damit die Arbeit besser aufgeteil und der Fortschritt gezeigt werden kann...
Einführung auf Deutsch
Das hier ist alles furchtbar BETA und nur was für ausgefuchste Relations-Experten.
Der verwendete Datensatz ist veraltet und ungenau, aber das beste, was wir haben. Daher importieren wir ihn auch nicht direkt für ganz Deutschland, sondern setzen auf die Mitarbeit der Community.
Das Ziel ist, dass wir für jedes Postleitzahlengebiet eine Relation haben, die wie folgt getaggt ist:
| Key | Value | Erklärung |
|---|---|---|
| type | multipolygon | erforderlich - So wie alle Relationen, die eine Fläche beschreiben. |
| boundary | postal_code | optional - Wenn die Relation bereits ein boundary-Tag hat, z.B. weil es sich um eine Stadtgrenze handelt, brauchen wir kein zusätzliches boundary=postal_code. Wenn das Postleitzahlengebiet aber eine eigene Relation ist, setzen wir dieses Tag, um zu erklären, worum es sich handelt. Auf keinen Fall soll ein allein stehendes Postleitzahlengebiet als boundary=administrative getaggt werden, denn ein Postleitzahlengebiet ist keine Verwaltungsgrenze. |
| postal_code | Postleitzahl | erforderlich - wir benutzen nicht addr:postcode, weil das für Adressen vorgesehen ist. Editoren sollten immer nur postal_code setzen, aber Nutzern wird empfohlen, trotzdem auf fälschlich gesetzte addr:postcode zu achten. |
| name | Name des PLZ-Gebiets | optional - der Name des PLZ-Gebiets, wenn es einen hat. Für Deutschland setzen wir einstweilen mal die PLZ selbst noch vorn in den Namen (also z.B. name=76133 Karlsruhe), damit man die Relationen im Editor unterscheiden kann. Obwohl das eigentlich überflüssig wäre. besser: statt name= note= verwenden. Die so getaggten Relationen lassen sich weiterhin im Relationseditor unterscheiden; zudem werden keine Namen virtueller Objekte irgendwo auf der Karte dargestellt. |
| postal_code_level | Zahl | optional - die Diskussion auf der talk-Liste hat gezeigt, dass einige Leute es gern hätten, wenn man an den Tags erkennt, wie feingegliedert die Postleitzahlen im jeweiligen Land sind. Dieses Tag wird mit vergleichbaren Zahlen wie admin_level belegt; wenn zum Beispiel Postleitzahlen in einem Land im allgemeinen ganz grob auf einer vergleichbaren Ebene wie Stadtgrenzen sind, würde man hier eine 8 eintragen (auch dann, wenn einzelne Postleitzahlengebiete in dem Land mal größer oder kleiner sind - sie Zahl soll wirklich nur eine Richtschnur sein). Für Deutschland nehmen wir 8. |
Sollte die Grenze des PLZ-Gebietes identisch sein mit einer bereits vorhandenen Grenze einer Stadt oder Gemeinde, so können die für PLZ-Gebiete relevanten Tags an die Grenzrelation "angeheftet" werden. Es ist hier nicht zwingend notwendig, eine eigene separate PLZ-Relation zu erstellen.
Diese Relationen sollen existierende Grenz-Ways mitbenutzen, wo sie gemeinsam verlaufen (wir gehen bis zum Beweis des Gegenteils davon aus, dass es keine Fälle gibt, in denen die PLZ-Grenze bewusst und absichtlich 10m neben der Gemeindegrenze verläuft und jeden Knick mitmacht).
Wenn eine Straße die Grenze des PLZ-Gebiets darstellt und die Häuser auf einer Seite der Straße zu einem anderen PLZ-Gebiet gehören als die auf der anderen Seite, dann soll die Straße selbst als Grenze in die Relation aufgenommen werden. Das ist rechts im Bild gezeigt: Hier gibt es eine Relation für das PLZ-Gebiet 12345, die die Ways 4,1,6 benutzt, und eine Relation für das Gebiet 12346 mit den Ways 7,1,8 (plus natürlich jeweils weitere, die das Gebiet abschließen und hier nicht gezeigt sind).
Wenn hingegen die ganze Straße zum gleichen PLZ-Gebiet gehört, dann muss die Grenze als eigener Way gezeichnet werden (linke Abbildung: Hier benutzt die Relation für 12345 die Ways 4,5,6 und die für 12346 die Ways 7,5,8).
So kannst Du mitmachen
Wir haben den Import vorbereitet, indem wir die Daten konvertiert und zum Download bereit gestellt haben. Jetzt ist die Community am Zug, um diese Daten von Hand in OSM einzubauen. Nur durch diesen manuellen Import lässt sich hinreichend sicherstellen, dass existierenden Grenzen mitbenutzt werden und es nicht zu unnötigem Durcheinander kommt.
Es gibt zwei Möglichkeiten, wie man den Import vornehmen kann: Entweder durch Abmalen von einem WMS-Server oder durch Importieren und und Anpassen einer vorbereiteten Datei.
Du solltest unbedingt sicher im Umgang mit Relationen sein. Der PLZ-Import wird erfordern, dass Du viele existierende Relationen änderst, Grenzen auftrennst, Teile davon für die PLZ-Region mitbenutzt, und so weiter, und dabei soll natürlich nichts kaputt gehen. Wenn Du nicht ganz genau weißt, wie die Relationen-Bearbeitung in Deinem Editor funktioniert, dann überlasse diesen schwierigen Import bitte denen, die das gut können!
Schritt 1: Diese Anleitung lesen
Lies diese Seite bis zum Ende durch und probiere die Technik aus, die Dir für Deinen Bereich am besten erscheint. Entscheide, ob Du Dir zutraust, einen ganzen PLZ-Bereich (also alle PLZen, die mit den gleichen zwei Zahlen anfangen) zu importieren.
Schritt 2: Einen Bereich auswählen
Trage Dich auf dieser To-Do-Liste für einen PLZ-Bereich Deiner Wahl ein (damit andere sehen, dass der schon in Bearbeitung ist).
Unter OSM-Inspector kannst Du Dir auch einen Überblick über die bisherige Abdeckung machen.
Schritt 3: Vorbereitete Daten herunterladen
Die Daten stehen auf download.geofabrik.de/plz als zip-files. Jeweils ein zip-File pro PLZ-Gebiet.
Die vorbereiteten Zipfiles sind irgendwann mal bei einem Server-Upgrade verloren gegangen. Da sie aber für jedes Gebiet eine Sammlung aller Admin-Relationen enthielten, wären sie inzwischen ohnehin hoffnungslos veraltet! Bei Bedarf kann Frederik Ramm für einzelne Gebiete aktuelle solche Dateien anfertigen.
Schritt 4a: Daten importieren mit WMS
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&
Achtung: Ganzen String kopieren (hört auf mit "..,plz_osm&"
In JOSM -> Einstellungen -> WMS/TMS -> "WMS-Server hinzufügen" aufrufen und dort den String in die erste Zeile "Dienst-URL eingeben" einfügen. Danach auf "Ebenen abrufen" klicken und das Gewünschte auswählen. Als letztes dieser Hintergrund-Ebene einen Namen geben.
Es sei darauf hin gewiesen, dass die Ausgangsdaten einen Versatz über etliche zig-Meter haben. Den kann man über den Ebenen-Dialog (Rechtsklick auf Hintergrund-Ebene) ausgleichen. Da dieser Versatz leider nicht konstant ist, muss man das je nach Gegend wiederholen.
Schritt 4b: Daten importieren mit vorbereiteten OSM-Files
PLZ und Relationen in JOSM laden. Eventuell alle PLZ-Gebiete komplett markieren und etwas verschieben, so dass sie besser zu den existierenden Grenzen passen (die PLZ-Daten haben einen kleinen Versatz). Dann
- Schnappe Dir ein beliebiges PLZ-Gebiet, indem Du auf irgendeine PLZ-Boundary-Linie klickst, die neben einer Admin-Boundary läuft und eine der entspr. Relationen aufmachst.
- Öffne Relations-Editor
- Markiere alles, so dass man das Gebiet auf der Karte identifizieren kann
- Schau Dir an, wo die Relation mit existierenden Admingrenzen parallel verlaeuft
- (!) schliesse den Relationseditor
- Splitte die Admingrenzen ueberall da auf, wo die PLZ-Linien von einer Admingrenze abzweigen, und verschmelze die PLZ-Linien mit den Admingrenzen an diesen Stellen
- öffne den Relationseditor wieder
- klicke eins nach dem anderen auf die Segmente der PLZ, die neben den Adminboundaries verlaufen; sie werden dann im Relationseditor markiert; loesche sie aus der Relation. (Loesche jetzt NICHT die Linien; entferne sie nur aus der Relation.) Füge fuer jedes so gelöschte Stueck die nötigen Admin-Boundary-Stückchen ein. Am Ende entsteht wieder eine schöne ringförmige Relation.
- klicke reihum die PLZ-Boundary-Linien des gerade bearbeiteten Gebiets auf der Karte an. Wenn eine davon schon zu keiner Relation mehr gehoert -> loeschen. Waehle die naechstbeste benachbarte Relation und Goto 1.
Eventuell lohnt es sich, JOSM auf das folgende elemstyles.xml umzustellen, bei dem die Adminboundaries nicht gestrichtelt waren und die Postcode-Boundaries deutlich gezeichnet wurden:
<rule>
<condition k="boundary" v="national"/>
<line width="1" colour="boundary#FF6600" dashed="true" priority="-10"/>
<icon annotate="true" src="misc/deprecated.png"/>
<scale_min>1</scale_min>
<scale_max>50000</scale_max>
</rule>
<rule>
<condition k="admin_level" v="1"/>
<line width="5" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="2"/>
<line width="5" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="3"/>
<line width="4" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="4"/>
<line width="4" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="5"/>
<line width="3" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="6"/>
<line width="3" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="7"/>
<line width="2" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="8"/>
<line width="2" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="9"/>
<line width="1" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="admin_level" v="10"/>
<line width="1" colour="boundary#FF6600" />
</rule>
<rule>
<condition k="boundary" v="administrative"/>
<line width="1" colour="boundary#FF6600" priority="-10"/>
<icon annotate="true" src="misc/deprecated.png"/>
<scale_min>1</scale_min>
<scale_max>50000</scale_max>
</rule>
<rule>
<condition k="boundary" v="postcode_area"/>
<line width="1" colour="boundary#0066FF" priority="-10"/>
<icon annotate="true" src="misc/deprecated.png"/>
<scale_min>1</scale_min>
<scale_max>50000</scale_max>
</rule>
Schritt 5: Erfolg prüfen und melden
Nach getaner Arbeit solltest Du im Arbeitsplan vermerken, dass der Bereich abgeschlossen ist. Danke für Deine Hilfe!
Anmerkung
Da die PLZ-Gebiete oft mit Gemeindegrenzen zusammen fallen, können diese gleich mit erfasst werden mit:
Relation:
- boundary=administrative
- admin_level=8
- de:amtlicher_gemeindeschluessel=xxx
boundary=administrative wird auch als PLZ-Grenze ausgewertet.
Die AGS (de:amtlicher_gemeindeschluessel) sind zu finden unter:
http://svenanders.openstreetmap.de/ags/Deutschland/index.html
Leider hat Sven die Bearbeitung dieser Daten eingestellt.
Siehe auch
English description
This page describes the import of post code areas for Germany. The import is currently in the planning stage.
We are not planning to run an automated import, rather make packaged .osm files available for small regions which local users can then open in their editor and work on before they are uploaded.
We are using a mesh of multipolygon relations, where the border between two post code areas is a way used by both these relations. The border between two post code areas is only ever one way (not two ways sharing nodes).
Our relations are tagged like so:
| Key | Value | Discussion |
|---|---|---|
| type | multipolygon | required - the proper type for any relation that describes an area. |
| boundary | postal_code | optional - if the postal code boundary coincides with another boundary, e.g. an administrative city area, we do not place an extra boundary=postal_code tag. But if the postal code boundary stands on its own, we use boundary=postal_code to explain what this is about. |
| postal_code | the postal code | required - we do not use addr:postcode since that is meant to be used for addressing. Editors should always use this tag, but for evaluating data it is recommended to also look out for potential addr:postcode tagging. |
| name | some name | optional - the name of the postal code area if it has one. If multiple postal code areas have the same name, it might make sense to include the post code itself in this name even though it is superfluous. 'better: use note= instead of name=. The so tagged relations still are distinguishable in the relation editor (this is the main reason for using name=* in the german part of this page). The advantage of using note= is that there won't be a rendering of names of virtual objects somewhere on the map. |
| postal_code_level | some number | optional - a discussion on the talk list showed that people would like to have an indication of postcode granularity. This tag is meant to be used in a similar fashion to admin_level with administrative boundaries; put a number here that roughly describes the post code granularity in admin_level terms, i.e. if postal codes generally are one per town then put 8 (even if occasionally a postal code describes a larger or smaller areas - this is just meant to give a general indication of the type of post code). |
Ways participating in these relations are tagged boundary=postal_code (but nothing else), and only if they would otherwise be untagged. This is for the convenience of simple editors and renderers, to give them a clue what the way is about. Note: often a way is an administrative boundary and postal code area boundary at the same time. Since such ways will usually be tagged boundary=administrative, it is impossible to see from the way alone that it also describes a postal code boundary. You have to look at the relation for this.
The remainder of the page is a German-language description of the import.