Tobias Jordans hat mit Grenzabgleich ein neues Webtool veröffentlicht, das OpenStreetMap-Verwaltungsgrenzen mit amtlichen Datensätzen in Deutschland vergleicht. Es berechnet Kennzahlen wie IoU oder Hausdorff-Abstand, um Abweichungen sichtbar zu machen und Mappern gezielt bei der Qualitätsprüfung und Verbesserung von Grenzdaten zu helfen.
Aufälligkeiten… Ich hab gleich mal im meinem Bereich vor der Haustür geschaut.
Tobias: da musst du noch mal schauen…
Unter https://grenzabgleich.osm-verkehrswende.org/brandenburg-gemeinden wird “Unterspreewald” gelistet. Unterspreewald ist aber ein Amt (admin_level=7) und keine Gemeinde! Eine Gemeinde wäre admin_level=8. Ich hab auch die Amtsgrenze visuell eben verglichen. Die Lageabweichungen sind wirklich vernachlässigbar…
Für mich wünsche ich mir mindestens auch eine separate Auswertung der offiziellen Ortsteile. Grenzen der Änder (hier für Brandenburg mittlerweile besser Gemeindeverbände) ist dann nett, aber mit sauberen echten Gemeindegrenzen wird das mit abgehandelt…
Mammi71
(One feature, Six mappers and still More ways to map it)
3
Interessantes Tool.
Aber ich bitte darum, dies mit Vorsicht zu genießen. Ich weiß nicht genau, welche amtlichen Daten verwendet werden, aber in meiner Gegend (zentrales Ba-Wü) sind die amtlichen Daten stellenweise sehr ungenau. Ich habe da letztens eine Gemeindegrenze anhand der Grenzsteine und der relativen Lage zum Weg deutlich korrigieren müssen, in dem Prüftool ist aber die alte ungenaue (amtliche) Lage enthalten.
Für einen summarischen Vergleich ist das Tool genial und ersetzt einige von meinen eigenen Skripten. Bspw. sind Staatsforsten sehr häufig nahegelegen Gemeinden in Teilen oder ganz zugeordnet, was faktisch falsch ist und für diese Gemeinden auch Auswertungen verwässern kann.
Bei der Nutzung von amtlichen Daten muss immer bedacht werden in welchem Kartenmaßstab diese bereitgestellt werden und wie es zu diesem Maßstab kommt. In der Regel werden ja keine Rohdaten oder zumindest bereinigte Daten herausgegeben, sondern für die weitere interne Verarbeitung bereits angeglichene / generalisierte. In vielen Bundesländern gibt es inzwischen zwar die Auflösung 1:25.000 die auch im digitalen relativ gut ist, vor 10-15 Jahren (aus denen viele Grenzverläufe meines Wissens ursprünglich stammen) waren das in der Regel aber eher 1:250.000 Maßstäbe. Das setzt entsprechend die geometrische Genauigkeit der einzelnen Knoten eines Verlaufs deutlich herab, als auch die Menge an Knoten die einen Verlauf bilden (die damals teilweise gar nicht eingemessen wurden, weils Sie im Verarbeitungsprozess ohnehin verloren gingen.)
Welche Daten in welchem Maßstab bereitgestellt werden und wurden, als auch wie die Umrechnung / Zusatzerfassung / Neuerfassung in einen genaueren Maßstab vonstatten ging, sehen wir bei Verwendung der Daten selten bis gar nicht (Fehlerraten oder andere Kennzahlen zur geometrischen Ungenauigkeit werden selten vorgehalten und noch seltener herausgegeben). Was in OSM händisch nachgearbeitet oder vermessen wurde, lässt sich da noch eher nachvollziehen.
Kurzum, bin voll bei @Mammi71 . Nehmt amtlich bereitgestellte Daten nicht als des Pudels Kern, eher als zusätzlichen Hinweis wenn in einem Vergleich der Daten etwas massiv im Argen liegt. Wir haben keine Ahnung wie diese Geometrien tatsächlich zustande kamen. Der Mensch vor Ort kann mit seinem Smartphone genauere und glaubhaftere Koordinaten erzeugen, als es jede x-beliebige zugelassene Quelle kann, wenn wir deren Verarbeitungsprozesse nicht kennen. Komplett neues erfassen ja (es lässt sich etwas leichter verbessern als von 0 schaffen), schon vorhandenes auschließlich auf der Basis nachbearbeiten, eher nein.
Schön wäre es allerdings trotzdem wenn die herangezogenen Daten des BKG (VG25), tatsächlich für OSM nutzbar wären. Für mich haben diese Vergleiche leider dann immer ein Gschmäckle wenn der OSM-Zusatz fehlt, bspw. wenn jemand diesen Vergleich dann als Quelle für eine Bearbeitung nimmt. Der Hinweis bzgl. der Kompbalität steht zwar schön aufgelistet auf der Seite, aber dennoch.
Ein paar Datensätze aus dem Geodatenzentrum haben ja zudem explizit den OSM-Hinweis in den Nutzungsbedingungen - siehe bspw. WFS Geographische Namen GN-DE (wfs_gnde) oder WFS Digitales Landschaftsmodell 1:250 000 (wfs_dlm250).
Für die die’s nicht gesehen haben SimonPoole's Diary | Our (the Swiss OSM communities) TIGER moment | OpenStreetMap geht auf die falschen Erwartungen ein die wir beim Gemeindegrenzenimport in 2011 in der Schweiz hatten (und das Tool von @habi, dass da jetzt die QA Daten dazu liefert, ist das, dass als Vorlage für das hier besprochene Werkzeug diente).
PS: neben dem eher langsamen und mühsamen Update der Grenzen um die Übereinstimmung mit den “offiziellen” Grenzdaten zu verbessern, gibt es auch einen unmittelbaren Nutzen: gestern hat jemand aus Versehen ein Punkt einer Grenze um 230m verschoben, was natürlich jetzt “sofort” auffällt.
Man kann pro Datensatz sehen, welche Vergleichsmethode verwendet wird (Gruppe " Datenquelle, Filter und Vergleichsregeln"). In diesem Fall ist es der de:regionalschluessel, der meiner Meinung nach das einige eindeutige Mittel ist um die Amtlichen Daten mit OSM abzugleichen (im Falle dieses Datensatzes). Hast du eine Idee, warum dieser Schlüssel hier verwendet wurde für diese Grenze?
Das wäre ein neuer Datensatz. Erstelle gerne einen Github Issue mit den nötigen Daten und Angaben, dann kann ich prüfen, ob das ins Tool passt.
Unter Issues · osmberlin/osm-boundary-checker-germany · GitHub gibt es ein Template für neue Datensätze, das ein paar Fragen stellt die recherchiert werden müssen…
Jeder Datensatz gibt an, welche Quelldaten verwendet wurden und wie der Abgleich konfiguriert ist. Für die Gemeindegrenzen in BaWü sind das (ausschließlich) BKG Daten in der höchsten, verfügbaren Auflösung.
Wenn die BKG-Daten tatsächlich von den Ground-Thruth-Daten abweichen, ist das eine interessante Problematik, die wir IMO mindestens gut sichtbar machen sollten, bspw. durch einen “note”-tag. Sonst kann es immer wieder vorkommen, dass wir die amtlichen Daten mit OSM abgleichen, da wir erstmal davon ausgehen sollten, dass das BKG seine Daten im Griff hat.
Update: Wenn wir ein Muster für diesen note-Tag (oder welchen Tag auch immer…) haben, kann ich diesen auch gerne nutzen um Hinweise im Tool anzuzeigen…
Als Ergänzung zu Neues Grenz-Fehlerprüftool - #7 by tordans : Ihr könnt auf jeder Detailseite und Übersichtsseite oben rechts den Link “Datensatz diskutieren” nutzen und darüber einen Github issue erstellen. Beim nächste Update wird dieser Issue dann verwendet als Hinweis. Das sieht dann bspw. so aus https://grenzabgleich.osm-verkehrswende.org/berlin-plz und gibt die Möglichkeit zu dem generierten Report auch eine Tonspur zu hinterlegen…
Ich habe mich bemüht all diese Informationen immer transparent auf der Seite aufzuführen, damit nichts unklar bleibt. Unter https://grenzabgleich.osm-verkehrswende.org/de-gemeinden-bw findest du am Ende der Seite (und auf jeder Detailseite) die Box " Datenquelle, Filter und Vergleichsregeln" die auf Verwaltungsgebiete 1:25 000, Stand 31.12. verlinkt und Alter der Daten (im Tool) und Layer etc. anzeigt.
Andere OpenData können vorgeschlagen werden über GitHub, wenn es lokal etwas besseres gibt.
Betonung liegt auf verfügbar.
In der Vergangenheit waren die Daten in BaWü (solange freigegeben) nicht auf auf Katastergenauigkeit, sondern leicht generalisiert, und das auch noch regional deutlich verschieden, vermutlich abhängig vom Bearbeiter der shape-files.
Das Ende vom Lied: Bei Abweichungen ist zunächst mal nicht sicher, was genauer ist - der Eintrag in OSM oder die BKG-Koordinaten.
Anm.: Bei Korrekturen basierend auf OTG-Kenntnis ist ein note-Vermerk hilfreich.
Es gibt zwei Farben wenn eine Zuordnung gefunden wurde (Grün amtlich, Orange-Gelb OSM) und blau wenn nur Amtlich. Wenn du auf die Fläche klickst, ist die Ansicht optimiert für den Vergleich dieser Grenze.
danke fürs Raussuchen, in diesem Fall ist es nicht verwunderlich, dass es Abweichungen gibt, weil 1:25000 bedeutet, dass die Daten ziemlich sicher bereits vereinfacht wurden.
Ich hab deinen Beitrag vormittag schon gesehen, kann aber erst jetzt reagieren… Wegen Mühlentag war ich anderweitig eingespannt…
Aha… eine zarte Idee hätte ich… Kann es sein, das diese Schlüsselnummern in Brandenburg umgestellt wurden und Altlasten verbieben sind?
Brandenburg hatte ja immer: Kreis - (Amt) - Gemeinde - Gemarkung - (Ortsteil)
Also Amt kann (daher Klammer) und Ortsteil kann (daher Klammer) [Enklaven/Exklaven klammere ich mal aus]
Mit Bildung der Verbandsgemeinde Liebenwerda ist das System in die Analen der Geschichte überführt worden. Diese Verbandsgemeinde ist was anderes das Amt zwischen Kreis und Gemeinde. Ich stecke bei diesen speziellen Geschichten nicht so drin, mit ist aber so, als wenn damit nun ein brandenburger Eigenweg adActa gelegt worden ist…
Nun hab ich einen Ansatzpunkt, um in nächster Zeit mal zu schauen…
Ja, der de:regionalschluessel ist ein weiteres Rabbit hole in das ich gefallen war… Ich habe mir https://grenzabgleich.osm-verkehrswende.org/tools/german-key?key=“120615114510” gebaut, um die historischen und aktuellen Schlüssel zu verstehen. Einige der Fehl-Abgleiche liege/lagen daran, dass veraltete Schlüssel in OSM waren. Das sehe ich aber hier nicht (dann gäbe es eine Warnung auf der Seite, von wann der Schlüssel kommt). Dieses Tool verwendet die unter “Datenquellen” aufgelisteten Sätze an Schlüsseln und merkt sich, wenn welche aufgelöst wurden um dazu Hinweise zu geben.
Nur als Ergänzung zur Bildung und Auflösung von Verbandsgemeinden oder Verwaltungsgemeinschaften wie Sie z.B. in Bayern heißen (und nicht immer exakt das gleiche sind).
Da malen die Mühlen manchmal erstaunlich langsam… selbst auf diesem Level.
Als ich das für unsere (auf amtlichen Daten basierende) Anwendungsfälle angepasst hatte, sind mir bei der Auswertung noch mehrere solche Themen aufgefallen. Bspw. auch das von mir bereits angesprochene Thema mit der Eingemeindung / Auflösung von Staatsforsten.
@streckenkundler was ist nochmal das Problem, das wir zu lösen versuchen?
https://grenzabgleich.osm-verkehrswende.org/brandenburg-gemeinden/feature/120615114510 gleich ja die amtlichen Daten von BB mit OSM ab und findet ein Match auf Basis des de:regionalschluessel=120615114510 und zeigt auch hohe Übereinstimmung außer diesem Zipfel, der in OSM anders zugeordnet ist. Ist jetzt nicht einfach die Frage, ob wir diesen Daten für OSM “folgen” wollen und die Grenzen entsprechend anpassen?
Am Rande: Ich ignoriere im Tool inzwischen den de:amtlicher_gemeindeschluessel. Ich habe noch nicht verstanden, warum wir den überhaupt machmal (nicht immer…) verwenden, denn der Regionalschlüssel ist ja immer präziser und auch immer vorhanden. Und man kann aus dem Regionalschlüssel immer die Informationen des Gemeindeschlüssels ableiten…
