Verwaltungsgrenzen Open Data Hessen

Die allgemeine Diskussion (https://forum.openstreetmap.org/viewtopic.php?id=74276&p=2) wird gerade etwas unübersichtlich.
Die Verwaltungsgrenzen in Hessen( Landesgrenze Hessen, Regierungsbezirke, Landkreise, Gemeinden, Gemarkungen, Fluren) sind open data.
Direkt zum Download der shape-files gehts es hier: https://www.gds-srv.hessen.de/atomfeed/DigVGr-epsg25832-shp.zip
Sie können mit opendata plugin von JOSM direkt angesehen werden.

Ich habe mir die auch mal angesehen und sie sehen ziemlich gut aus (=Grenzen führen entlang von Feldergrenzen und nicht kreuz und quer durch die Landschaft, wie da mit den existierenden Grenzen ist)

Ein paar Macken haben die aber auch: In Pohlheim ist ein Stück Bach mitten in der Gemeinde Gemeindegrenze.

Bei Gießen stimmen die existierenden Grenzen teilweise gut mit nur ein paar Metern Versatz (https://www.openstreetmap.org/#map=17/50.56237/8.65911)
und teilweise ist die existierende Grenze soweit vereinfacht, dass sie über 100m falsch ist (https://www.openstreetmap.org/#map=16/50.5410/8.8018).

Man muss sich bei den shapes immer klar machen, dass man die beim derzeitigen Stand der OSM-Dinge in HE nicht einfach großflächig “importieren” kann,
realistisch ist imho für die OSM-Grenzrelationen
A) Node-Korrektur auf WMS-Basis “Liegenschaftskarte” (kann jede/r)
B) Way-update segmentweise per shape (nicht untrivial, kann ich nur mit JOSM)
das schließt sich aber nicht gegenseitig aus.

Dass administrative Grenzen “irre” Verläufe haben, ist nichts Ungewöhnliches. Es gibt sogar Fälle, wo sie durch Häuser gehen.

Verlauf entlang Feldgrenzen ist ein gutes Indiz, da die Flurstücke sich fast immer an den admin-Grenzen orientieren.
Sonst muss der Eigentümer an zwei Stellen Grundsteuer zahlen.

Für die Umwandlung von shape-Umrissen in OSM-kompatible Segmente gab es mal ein Skript in QGIS. War aber nichts für Anfänger.
Für das Ersetzen von Grenzsegmenten ist das Plugin “Contour-merge” sehr gut geeignet.

Vergleiche tun ja gut…

Hier in Brandenburg basieren alle auch für OSM verwendbaren Verwaltungsgrenzen auf den Katastergrenzen. Ich beobachte keine Generalisierung mehr, wie es vor Jahren üblich war. Man muß aber immer sagen: “soweit diese Grenzen im Kataster lagekorrigiert sind” Es gibt hier noch immer Prozesse, mit denen sukzessive Grenzverbesserungen stattfinden. Manchmal stößt man in Amtsblättern auf entsprechende Veröffentlichungen der Katasterämter.

Mit dem Hintergrund wäre ein (partieller?) Import zwar zunächst nett, aber nicht nachhaltig. Solche Grenzen verändern sich ständig.

Meiner Meinung reicht es aus, diese Daten nutzen zu dürfen, diese zu nutzen und bestehende Grenzen nach WMS hinreichend lagezukorrigieren, wenn man in einem Gebiet aktiv ist und daran denkt (letzteres gelingt mir auch gerne mal nicht)…

Sven

Ist das sauberer wenn man die Geometrie der existierenden ways ersetzt oder sollte man den alten way durch den neuen in der Relation ersetzen?
(Alles natürlich in kleinen Changesets)

Das Zerlegen in Segmente geht mit der SAGA-Funktion shared polygon edges, außer an der Landesgrenze, weil es da keine Nachbargemeinde mehr gibt.

Zum Nachbarland hin sollte man sowieso überprüfen, welche Grenzen genauer sind. Zwischen Bayern und BaWü waren die Abweichungen nach Koordinatentransformation nur wenige Zentimeter.

Das Abstimmen auf die Segmente durch die Nachbarlandgemeinden ist auf jeden Fall Handarbeit.

Geht natürlich beides, aber die Historie wird nur erhalten, wenn man lediglich die Geometrie ersetzt. An den Außengrenzen geht es fast gar nicht anders, sonst zerschießt man die Nachbarrelationen dort.

Hatte schon bei einem shape-Projekt mit Schutzgebieten sehr gute Erfahrungen mit der Funktion “Geometrie ersetzen” (in “OptionaleWkz”) in JOSM gemacht - die OSM-id und Versionsgeschichte bleibt dabei nämlich erhalten.
Mein Workflow bei diesem HE-Grenzsegment (ohne Sonderfälle wie Bach bildet Grenze),
https://www.openstreetmap.org/way/310847805/history
mit 2 getrennten Ebenen in JOSM (!)

  • shape-Datei 1x in JOSM einlesen (überflüssige Regionen ggf. löschen) und für spätere Verwendung als irgendwas.osm lokal speichern.
  • die Gesamtgrenze einer Gemeinde aus irgendwas.osm in die Arbeitsebene kopieren und dort “Bei Quellposition einfügen”
  • Diese Gesamtgrenze an den 2 späteren OSM-Vereinigungspunkten trennen und den unbenötigten Teil löschen
  • behördliche Tags am neuen Grenzsegment löschen
  • 2 vorhandene OSM Grenzepunkte mit den beiden Enden des neuen Segnments verbinden
  • Neues + (paralleles) altes Grenzsegment (muss vollständig eingelesen sein) markieren + Funktion “Geometrie ersetzen”
    JOSM fragt jetzt ob die Relationszuordnung(en) beibehalten werden sollen - Klar, immer und alle.

Kleine generelle Anmerkung: Das OpenData-Plugin in JOSM sollte eventuell nötige Transformationen nach WGS84 automatisch erledigen, das erleichtert die Arbeit ungemein. Falls doch Fehler darin sind, müssten sie sich in erheblichem systematischen Versatz zeigen.