Von talk-de: Die Firma Infas GEOdaten ([url]http://www.infas-geodaten.de/[/url]) hat der Geofabrik freundlicherweise aus eigenem Datenbestand die Geometrien aller Kreisgrenzen in Deutschland mit Stand vom Ende 2005 zur Verfügung gestellt und dem Import in die OSM-Datenbank zugestimmt. Wir haben uns die Daten angesehen und mal vorläufig geprüft, ob sie nutz- und konvertierbar sind. Wir haben vorher nichts gesagt, weil wir keine ungefangenen Fische verkaufen wollten, aber es sieht so aus, als ob die Daten ganz nützlich sein könnten. Die Daten sind teilweise nicht aktuell, aber die Geometrien sind besser aufgelöst als die meisten Daten, die wir derzeit haben (die kommen zum großen Teil aus dem Import der GADM-Daten (UNEP/GRID)). Wir wollen daher die neuen Daten (zumindest teilweise) importieren. Format der Daten Wir haben die Daten als Shapefiles mit einem Polygon pro Kreis bekommen. Zusätzlich ist jeweils der Kreisbezeichner aus dem amtlichen Gemeindeschlüssel (AGS5) (siehe http://de.wikipedia.org/wiki/Amtlicher_Gemeindeschlüssel) und der Name des Landkreises bzw. der kreisfreien Stadt enthalten. Die Polygone gehen an der Küste nicht aufs Wasser hinaus, sondern dann die Küstenlinie lang. Diese Daten wollen wir so konvertieren, dass sie folgendes Format haben: (Siehe auch [url]http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries[/url] .) Für jeden Kreis wird eine Relation mit folgenden Tags angelegt: type=multipolygon boundary=administrative admin_level=6 [siehe http://wiki.openstreetmap.org/index.php/Key:admin_level] name=[Der Name] de:amtlicher_gemeindeschluessel=[AGS5] source=infas_geodaten_kreisgrenzen_import ([URL einer noch anzulegenden Wiki-Seite]) Mitglieder dieser Relation sind die einzelnen Ways, die die Grenzen ausmachen. Die Grenzen werden dabei so in Ways aufgeteilt, dass sich angrenzende Kreise einen gemeinsamen Way teilen können. Die einzelnen Ways haben die folgenden Tags: boundary=administrative admin_level=6 An den Bundeslandgrenzen bzw. an der Staatsgrenze haben die einzelnen Ways entsprechend kleinere admin_levels: admin_level=2 (an der Staatsgrenze) admin_level=4 (an den Grenzen der Bundesländer) Für die Bundesländer werden jeweils ebenfalls Relationen angelegt: type=boundary boundary=administrative admin_level=4 name=[Name des Bundeslandes] de:amtlicher_gemeindeschluessel=[AGS2] source=infas_geodaten_kreisgrenzen_import ([URL einer noch anzulegenden Wiki-Seite]) Für die Staatsgrenze wird die folgende Relation angelegt: type=boundary boundary=administrative admin_level=2 name=Bundesrepublik Deutschland source=infas_geodaten_kreisgrenzen_import ([URL einer noch anzulegenden Wiki-Seite]) Das Vorgehen haben wir uns so vorgestellt: 1. Ab sofort steht im OSM Inspector ein neuer View mit den aktuell in OSM vorhandenen Grenzen zur Verfügung. Der View enthält zusätzlich einen Layer mit den neuen Kreisgrenzen. Schaut Euch das bitte an und meldet Euch, wenn ihr irgendwelche Probleme seht. [url]http://tools.geofabrik.de/osmi/?view=kreisgrenzen[/url] 2. Wer von Kreisgrenzen weiß, die bisher besser sind als die neuen Daten, z.B. weil er selbst für seine Stadt sehr gut aufgelöste hat oder dergl. soll sich bitte melden. Wir können dann diese Bereiche vom späteren Import ausschließen bzw. diskutieren, wie wir im Einzelfall weiter vorgehen. Genauso wenn irgendwo Fehler in den Daten sind, z.B. weil seither Kreise zusammengelegt wurden usw. 3. Wir importieren die neuen Daten (*zum Format siehe oben). Die Tags der alten Daten werden geändert (z.B. boundary=administrative ändern in obsolete_boundary=administrative), sodass sie als Referenz noch da sind, aber nicht mehr auf der Karte erscheinen. 4. Jeder kann sich die neuen Daten anschauen und ggf. ändern, Lücken schließen, an andere Daten anpassen usw. Die alten Daten sind im ja Editor noch sichtbar. 5. Wir löschen nach ausreichender Übergangszeit die alten, nun überflüssig gewordenen Daten. (In der History bleiben sie aber natürlich erhalten.) Das Ganze ist natürlich schon eine größere Operation und wird einiges an Arbeit nach sich ziehen. Aber wir denken, das ist es wert. Wie klingt dieser Plan? Irgendwelche Einwände? Können wirs irgendwie besser machen? Jochen – Jochen Topf jochen@remote.org [url]http://www.remote.org/jochen/[/url] +49-721-388298 Wikiseite: [url]http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005[/url]
Hallo Jochen, na endlich mal eine Fa. die ihr Versprechen gute Daten zu liefern wahr gemacht hat. 
(Infas GEOdaten meine ich) Man hat ja schon des öfteren über wahre Schätze die zum Projekt beigesteuert werden sollten, lesen können. Ich habe mir mal den Bereich zu dem ich etwas sagen kann (Lahn-Dill-Kreis) näher angeschaut. Da ich beruflich fast jeden Tag die Kreiskarte vor Augen habe, kann ich für diesen Bereich bestätigen das soweit alles korrekt erscheint. Die Daten sind natürlich um ein vielfaches präziser als der bisherige Grenzverlauf. Also rein damit… 
Voting: YES Georg
Ich habe mir die Kreisgrenzen um Leipzig und Umland angeschaut, da wir dort noch einen recht großen Bedarf haben. Da wir aber gerade eine Kreisreform hatten sind es immer noch nicht die aktuellsten Kreisgrenzen. Sie sind aber immer noch genauer als die existierenden. Evtl kann man den Kreis Leipzig, Leipziger Land und Muldentalkreis direkt beim importieren zusammenlegen. Wir diskutieren das am Donnerstag auf dem Stammtisch mal. Theorethisch sollten ja die äußeren Grenzen aller drei Kreise bestehen geblieben sein. Ansonsten sehen die Grenzen schon sehr gut aus.
In meiner Heimatregion (Landkreis Osterholz) beträgt die Abweichung von der tatsächlichen Kreisgrenze maximal 20 Meter. Bei einem Import würden also, abgesehen von der Tatsache, dass Flussverlauf und Kreisgrenze nicht mehr identisch sind, keine wichtigen Daten verloren gehen. Gruß FK270673
Hallo, an den Wasserlinien sieht es nicht so gut aus: http://tools.geofabrik.de/osmi/?view=kreisgrenzen&baselayer=Mapnik&opacity=0.30&lon=13.08766&lat=54.31953&zoom=17&overlays=coastline,boundary_relations_4,boundary_relations_5,boundary_relations_6,boundary_relations_7,boundaries_from_infas_geodaten,boundary_ways_2,boundary_ways_4,boundary_ways_5,boundary_ways_6,boundary_ways_7 Grüße.
Ich kann die Aussage von north nur bestätigen, die Küstenlinie sieht nicht gut aus. Sie müßte manuell nachbearbeitet werden, ansonsten liegen küstennahe Wege wieder im Wasser. http://tools.geofabrik.de/osmi/?view=kreisgrenzen&baselayer=Mapnik&opacity=0.30&lon=13.18644&lat=54.26330&zoom=16&overlays=coastline,boundary_relations_2,boundary_relations_4,boundary_relations_5,boundary_relations_6,boundary_relations_7,boundaries_from_infas_geodaten,boundary_ways_2,boundary_ways_4,boundary_ways_5,boundary_ways_6,boundary_ways_7 Die Genauigkeit der Kreisgrenzen scheint aber genauer zu sein (soweit ich das einschätzen kann), also rein damit.
@sabmatt54: es werden doch nur Grenzen eingetragen, die Küstenlinie wird nicht verändert. Also landen auch keine Wege im Wasser. Gruß Jonas
@John07: Deine Aussage: “Die Polygone gehen an der Küste nicht aufs Wasser hinaus, sondern dann die Küstenlinie lang.” Aus diesem Grund dachte ich, die Küstenlinie wird der Kreisgrenze angepasst. Gruß Matthias
Die Grenzlinien sind super… die Grenze zwischen Deutschland und Österreich ist bei openstreetmap sehr ungenau eingezeichnet… durch diese infasdaten stimmen die Grenzen selbst in der Pampa auf den Meter genau.
Die Daten sehen sehr gut aus. Der Genauigkeit kann man manuel nachtragen, das dürfte insbesondere bei Küsten oder wichtigen Strassen eigentlich kein Problem sein. Für die OSM Öffentlichkeitsarbeit sind diese Daten von besonderer Bedeutung. Google & Co. haben solche Daten nicht. Also rein damit und an die Öffentlichkeit gehen.
Hallo Jochen, habe zufällig gestern die Stadtgrenze meiner Heimatstadt Niederkassel überarbeitet und die UNEP-GRID Grenze nach Köln gelöscht, weil die sehr ungenau war. Die Infas Daten liegen mit wenigen Ausnahmen fast passgenau, sind aber vermutlich noch etwas besser. Schade nur, dass infas nicht auch die Kommunalgrenzen spendiert hat… Gruß, Roland
Hallo Jochen, ich habe mir mal die Grenzen der Kreise Altenkirchen WW, Oberbergischer Kreis bzw. Siegen-Wittgenstein angeschaut (die zum Teil auch noch mit der Grenze der Bundesländer Rheinland-Pfalz, Nordrhein-Westfalen bzw. Hessen zusammenfallen)! Sieht viel besser aus, als die vorhandenen! Jetzt passen die Grenzen auch zu den geographischen Gegebenheiten. Rein damit! Gruß Klaus
Na, das freut mich ja zu hören. Grund genug drüber nachzudenken, zumindestens die “alten” PLZ5 strukturen auch freizugeben … hmmm. vg, mh.
Hallo Michael, wie genau sind die importierten Kreisgrenzen?
ja, das wäre beim Routing und Adressen zuordnen sicher sehr hilfreich! Gruss, Markus
Das sieht in der Tat sehr viel besser aus. Habe uebers Wochenende die mir von der Stadt Dinslaken zur Verfuegung gestellten Grenzen eingetragen: Weitestgehend deckungsgleich mit den Infas GEOdaten: http://tools.geofabrik.de/osmi/?view=kreisgrenzen&baselayer=Mapnik&opacity=0.30&lon=6.77025&lat=51.57403&zoom=12&overlays=coastline,boundary_relations_2,boundary_relations_4,boundary_relations_5,boundary_relations_7,boundaries_from_infas_geodaten,boundary_ways_2,boundary_ways_4,boundary_ways_5,boundary_ways_7 Viele Gruesse, Dirk
Hallo,
Vorausgesetzt, ich habe das Konzept der Relationen richtig verstanden, ist hier ein admin_level-Tag doch nicht angesagt (die Ways koennen ja schliesslich auch Teil einer Orts-/Stadtteil-Grenzen-Relation sein), oder? Gibt es denn auch schon eine Vorstellung, wann der Import stattfinden soll? Viele Gruesse, Dirk
Meiner Meinung nach sollte man den admin_level doppelt führen, wobei er nicht wirklich doppelt ist… In der Relation gibt er den admin_level der Fläche an: des Kreises, des Regierungsbezirkes, des Ortes, … also mehrere übereinander. An der Grenze selbst steht nur die höchstwertige Grenze: so wie auf Karten üblich: Kreisgrenze verdrängt Ortsgrenze, Landesgrenze verdrängt Kreisgrenze. Natürlich kann man das auch aus den Relationen rausrechnen, aber an der Bundesgrenze können beidseitig durchaus Rattenschwänze dran hängen: Bundesland, Regierungsbezirk, Kreis, verbandsgemeinde, Ortsgemeinde, Stadtbezirk, Stadtteil, Stadtviertel, statistische Bezirke, irgendwann auch noch Schornsteigerfegerbezirke, Bäckerei-Innungsgrenzen, … 
So manches einfache Mappingprogramm wird froh sein, wenn es EINEN Wert vorfindet, den höchsten level dieses Schnippsels von Grenze… Im Beispiel oben kommt level 6 nicht in Konflikt mit Ortsgrenzen, weil 6 höherwertiger als diese und daher korrekt überschrieben wird. Das Konfliktmanagement mit den Regierungbezirken und Bundesländern werden die Importeure hoffentlich hinkriegen
Die Kreisgrenze Wesel (NRW, AGS_05170) habe ich gerade aus Daten der Kreisverwaltung erstellt: rel_58745. Bitte vom Import ausnehmen. Vielen Dank, Dirk
Würde auch diesen Fehler hier beheben: http://openstreetbugs.appspot.com/?lon=10.3745320585&lat=49.67041759660001&zoom=15
Die Daten schauen sehr interessant aus Auf diese Daten habe ich schon gehofft. Gibts schon eine Planung wann die Daten eingespielt werden? Derzeit doch nur testweise bei den Geofabrik Tools, oder?