Nach einem Tweet [1] von GIScienceHD + HeiGIT (@GIScienceHD) gibt es große Neuigkeiten bzgl. neuer Funktionen bei osmlanduse.org [2], nämlich separate Datenschichten, Basisschichten für eine schnelle visuelle Analyse. In [2] heißt es zum Projekt:
“OSM Landuse Landcover ist eine WebGIS-Anwendung, um die OpenStreetMap-Datenbank speziell im Hinblick auf Landnutzungs- und Landbedeckungsinformationen zu durchsuchen.” [2]
Nach kleiner Suche im Quelltext habe ich auch die WMS-URL gefunden und ins QGIS eingebunden:
Nach dem erstaunlichen Echo* auf meinen vorgestrigen Beitrag “QGIS-Tipp: Flussbreiten ermitteln, aber wie?” [1] hier nun noch die angekündigte Ergänzung. Am eigentlichen Algorithmus ändert sich gar nichts, der bleibt wie beschrieben. Um jedoch noch bessere Ergebnisse zu erhalten, macht es Sinn, sich noch mal die Generierung des Fluss-Mittellinie genauer anzuschauen. Ziel war es, bessere Mittellinien zu erzeugen, also am besten aus den Uferlinien direkt und nicht aus einem Datenbestand anderer Herkunft und Erfassungsgenauigkeit. Die gesuchte Funktion ist die “Centerline”. Ich habe etliche Funktionen in verschiedenen Plugins getestet, die meisten schlugen aber leider fehl, ob es an mir lag oder meinen Daten …, ich weiß nicht. Erfolg hatte ich mit der “Skeleton”-Funktion im Plugin “BecaGIS” [2] angewendet auf das Gewässer-Polygon. Kleine “Faserstücke” an den Rändern wurden mittels Selektion (z. B. $length < 40 eleminiert). Die Erzeugung dieser Mittellinie ist dem Schritt 1 zuzuordnen.
Die so verbesserte Mittellinie führt marginal zu besseren Ergebnissen, die Senkrechten auf der Mittellinie stehen mitunter etwas rechtwinkliger zu den Uferlinien (vgl. Screenshot 6).
Hinweis: Ein wichtiger Tipp nach der Verlässlichkeit der Uferlinien wurde noch in Kommentar 3 in [1] gegeben, also welchen Ursprung haben diese und was verbirgt sich wirklich dahinter. Ist es das mittlere Wasser, quasi der Durchschnitt z. B. im Jahr oder das Ergebnis einer Vermessung zu einem zufälligem Datum oder …
Und hier das Ganze noch mal als Galerie zum Blättern:
* … innerhalb von ca. 48h: – im Twitter ca. 9453Aufrufe, 28 Retweets, 146 Likes, 30 neue Follower 🙂 – FaceBook: 166 Likes, 50x geteilt
Vor kurzem gab es in den Kommentaren des Beitrages “QGIS-Tipp: Länge und Breite eines Polygons?” [1] die Frage nach der Ermittlung von Flussbreiten. Angepingt durch diese Frage habe ich mich mal mit einer Lösung beschäftigt und bin in [2] und [3] fündig geworden, um dann gleich mal folgendes Kochbuch für QGIS am Beispiel der Saale in Halle (Saale) zu schreiben:
Schritt 1: Die nötigen Ausgangsdaten besorgen, hier die Uferlinien (entnommen aus der Digitalen Stadtgrundkarte der Stadt Halle) und Fluss-Geometrien (entnommen aus den OSM-Daten mittels Overpass Turbo Export gesucht nach “river”) – diese werden als annähernde Mittellinien des Flusses angenommen. Es muss übrigens nicht die exakte Mittellinie sein, aber, je mittiger, desto besser, weil der rechte Winkel zum Ufer insbesondere in Kurven besser erreicht wird.
Schritt 2: Flussmitte “Auflösen” (dissolve), um einen durchgehenden Linienzug zu generieren und somit nur einen Start-Punkt für die Stützstellen-Interpolation in Schritt 4 zu haben
Schritt 3: Glätten Flussmitte-Mittellinie mit der Funktion “Glatt” (smooth), ich habe mit vier Iterationen getestet
Schritt 4: Punkte alle 100m auf Mittellinie mittels “Punkte entlang einer Geometrie” erzeugen
Schritt 5: Senkrechte Geometrien auf Punkten berechnen mittels “Geometrie nach Ausdruck” mit einer Weite, die größer als angenommene maximale Breite (hier 80m) ist, hier mit dem Ausdruck aus [3].
Schritt 6: “Zuschneiden” an Ufergrenzen (Clip) und Schritt 7: Symbolisieren mit Pfeilen und Bemaßung
Optional dann Schritt 8: Freuen, nach Verbesserungen suchen und ggf. ein QGIS-Model draus machen oder am Besten einfach mal ein vollkommen dynamisches Modell mit dem Geometrie-Generator erzeugen, also quasi OnTheFly-Generieren ohne Zwischenthemen? Und vielleicht kann man noch nach [4] die Mittellinie des Flusses optimieren? Ich werde es testen.
Und weiter geht es noch mit der Analyse, hier die breiteste Stelle der Saale in Halle am Wehr in Trotha:
. . . und die Prüfung der Ergebnisse mit dem Messwerkzeug – sogar an den Inseln funktioniert es perfekt. Hier gerundete 32m + 57m = 89m:
Und hier das Ganze noch mal als Galerie zum Blättern:
Am 14. März veröffentlichte die Graphhopper-Community in ihrem Blogeintrag “GraphHopper Routing Engine 7.0 Released” [1] die neue Version 7.0 des bekannten freien Routing-Systems.
Screenshot: Blogeintrag mit der Graphhopper 7.0 Ankündigung (Quelle [1])
Die wichtigsten Neuerungen betreffen:
Verbesserte Umsetzung von Abbiegebeschränkungen
Anpassbares Routing
Benutzerdefinierte Bereiche
und … viele andere Verbesserungen und Bugfixes
Eine detaillierte Liste der Neuerungen findet Ihr auf GitHub [2]
Neulich an der GIS-Hotline gab es die Frage, wie man im QGIS Länge und Breite von Polygonen bestimmt. Die Lösung ist recht einfach, ma nutzt die Toolbox-Funktion “Minimaler gerichteter Umgrenzungsrahmen” [1].
Ich hab es mal getestet, hier eine kleine Anleitung inkl. Generierung geeigneter Testdaten:
Schritt 1: Schaffen von Testdaten – Generieren von mehreren zufälligen Punkten über “Vektor / Forschungswerkzeuge / Zufällige Punkte in Grenzen”
Schritt 2: Mittels Feldrechner die Spalten für Breite, Höhe und Drehung erzeugen, bei mit “b”, “h” und “d” und jeweils mit Zufallszahlen befüllen, z. B. bei der Drehungsspalte “d” mit “rand(0,359)”
Schritt 3: Erzeugen der Flächengeometrien mittel der Toolbox-Funktion “Rechtecke, Ovale, Rauten (variabel)”: Ich habe es mal mit “Ovale” probiert unter Nutzung der Spalten “b”, “h” und “d” meiner zufälligen Punkte
Schritt 4: Nutzen der Toolbox-Funktion “Minimaler gerichteter Umgrenzungsrahmen” [1] auf das Thema mit den Ovalen und man erhält im Ergebnis die BoundingBox in der extakten Orientierung
FINALE: Schritt 5 – hier die eigentlich Antwort auf die o. g. Frage nach Länge und Breite des Polygons: Mittels “Vektor / Geometrie-Werkzeuge / Polygone zu Linien…” werde die Umgrenzungsrahmen in Linien umgewandelt und in deren Sachdatentabelle findet man dann Länge und Weite
Ergänzung: Nach dem Kommentar von Matthias habe ich die Umgrenzungsrahmen testweise für alle Gewässer von Halle (Saale) gerechnet und kann keine Fehler feststellen, vgl. folgender Screenshot. Immerhin ist die Saale mit Inseln und Ausbuchtungen wirklich geometrisch recht kompliziert, insgesamt 850 Polygon bei 124099 Nodes:
Über ChatGPT und Geo [1], aber auch die Erleichterung bei der Nutzung von Overpass Turbo Anfragen auf die OpenStreetMap-Daten mittels QuickOSM [2] und whatiswhere [3] habe ich hier schon mehrfach berichtet. Heute nun die direkte Nutzung von ChatGPT und die Ausgabe von Overpass Turbo Anfragen, nur mit Bordmittlen sind zwei Schritte nötig:
Schritt 1. Ich stellte ChatGPT einfach mal folgende Aufgabe: “Zeige mir alle Brunnen in der Innenstadt von Halle (Saale) in den OpenStreetMap-Daten als Overpass Turbo Abfrage.”
Als Antwort kam als Abfrage-Text folgender Code einer Overpass Turbo Anfrage zurück:
/* Suche nach Brunnen in der Innenstadt von Halle (Saale) */ [out:json]; // Begrenze die Suche auf die Innenstadt von Halle (Saale) area[name="Halle (Saale)"]->.boundaryarea; // Suche nach allen Brunnen innerhalb der Begrenzung node[amenity="drinking_water"](area.boundaryarea); out center;
Schritt 2: Gibt man diesen Code nun im Overpass Turbo ein, erhält man Folgendes Ergebnis:
Wem nun zwei Schritte noch zu viel sind, der kann sich vielleicht auch mal ChatGeoPT [4], [5], [6], [7] anschauen, momentan im “Proof of Concept”-Status. Dort sind in einer “Spielzeugdemo” bei Schritte via 200 Zeilen Python-Code vereinigt, es sieht schon gut aus, man darf gespannt sein!
Für alle, die bei der FOSSGIS 2023 nicht live dabei sein konnten, besteht wie immer die Riesenchance, sich die Beiträge im Nachgang anzuschauen. Dank des CCC sind mittlerweile alle Vorträge des FOSSGIS 2023 online verfügbar in der Full Playlist als Video [1] und Audio! Zur Orientierung hier noch mal der Link zum FOSSGIS 2023 – Programm [3].
Danke allen Helfer:innen in Organisation, Regie, Videobetreuung sowie Sessionleitung und den Vortragenden!
Screenshot: Die vollständigen media.ccc.de-Streams der FOSSGIS 2023 (Quelle [1])
Overpass Turbo ist eine geniale Oberfläche für Abfragen auf die OpenStreetMap-Daten, sie wurde hier beim #geoObserver schon oft thematisiert [1]. Wer sich schon mal damit beschäftigt hat, wird schnell bemerkt haben, dass die Abfragesprache doch recht kompliziert erscheint, in jedem Fall jedoch gewöhnungsbedürftig ist. Der Wizzard hilft weiter, bei komplizierten Anfragen aber eher weniger. Um die Arbeit zu vereinfachen gibt es für QGIS-Nutzer das z. B. QuickOSM-Plugin [2]. Eine neue Erleichterung gibt es jetzt mit whatiswhere [3]. Einfach Suchbegriff eingeben und mit Defaulteinstellungen suchen. Verblüffend schnell und gut präsentiert findet Ihr die Suchergebnisse, die dann auch in Excel exportiert werden können. Wiederkehrende Suchen können gespeichert (*.mapp) und bei Bedarf geladen und genutzt werden. Ich habe das Ganze mal mit der Suche nach “bar” im halleschen Paulusviertel (Download als paulusviertel_bar.mapp) getestet
Screenshot 1: Mein Test mit der Suche nach “bar” im halleschen Paulusviertel Screenshot 2: Die Treffer bei der Suche nach “bar”
Gesucht wird offensichtlich in allen/vielen OSM-Tags, was mitunter zu “eigenartigen” Treffern führt?
Screenshot 3: Warum wird auch das Ärztehaus gefunden?
Schaut man sich die Original-OSM-Daten dann an, findet man die Auflösung schnell:
Screenshot 4: Die Erklärung, “bar” kommt in “scheinbar” vor
Der Tipp kam aus der Wochennotiz 660 (Weekly OSM) [4], dort heißt es:
In den 90er Jahren war der Begriff “Umweltatlas” so ein Buzzword, ich durfte den Umweltatlas von Halle [1] seit 1991 mitbauen, am 12.12.2002 ging er öffentlich an den Start, übrigens als erster in Sachsen-Anhalt. Die meisten dieser Umweltatlanten sind jedoch beschränkt auf die reine Datenlage, im günstigsten Fall enthalten sie auch die Metadaten, erklären die Daten, deren Herkunft, Genauigkeit, Quellen, Historie, … Berlin geht einen deutlichen Schritt weiter, es thematisiert im Umweltgerechtigkeitsatlas [2] die Umweltgerechtigkeit! Dort heißt es:
“Was ist Umweltgerechtigkeit?
Die Lebens- und Umweltqualität in den Quartieren der Hauptstadt sind sehr unterschiedlich. In vielen Teilen Berlins – vor allem im hochverdichteten Innenstadtbereich – konzentrieren sich gesundheitsrelevante Umweltbelastungen, wie Verkehrslärm, Luftschadstoffe, unzureichende Ausstattung mit Grünflächen und bioklimatischen Belastungen. Viele Gebiete haben gleichzeitig eine hohe soziale Problematik und sind überproportional durch Mehrfachbelastungen betroffen. Diese Themen werden in Berlin unter dem Begriff Umweltgerechtigkeit diskutiert und gewinnen auch vor dem Hintergrund des Klimawandels an Bedeutung.
Umweltschutz und soziale Gerechtigkeit sind aufs engste miteinander verknüpft und betreffen vor allem die Metropolenräume. Menschen mit geringem Einkommen und niedriger Bildung sind in Deutschland oft höheren Gesundheitsbelastungen durch Umweltprobleme ausgesetzt als Menschen, die finanziell bessergestellt sind. Sie wohnen oft an stark befahrenen Straßen und sind besonders häufig von Lärm und Luftverschmutzungen betroffen. Umweltgerechtigkeit verfolgt das Ziel, umweltbezogene gesundheitliche Beeinträchtigungen zu vermeiden und zu beseitigen sowie bestmögliche umweltbezogene Gesundheitschancen herzustellen.” [2]
Screenshot: Die Karte der Integrierten Mehrfachbelastung (Quelle [2]) inkl. WMS/WFS-URLs
Die Karten und Daten sind offen und können via WMS und WFS ins eigene GIS eingebunden werden, ich hab es mal mit QGIS getestet.
Screenshot: Die WMS-Daten der Karte der Integrierten Mehrfachbelastung (Quelle [2]) im QGIS
Hier Original-Tweet von @MontyDelMuro bzgl. aktueller Berliner Entwicklungen wie A100 und Tempelhofer Feld im Zusammenhang mit der Umweltgerechtigkeit [5]: