So schnell vergeht die Zeit: vor 5 Jahren [1] habe ich zum 20. gratuliert und jetzt? Die in vielen GI-Systemen eingebaute und somit auch von vielen Anwendern (mitunter auch unbewusst*) genutzte GDAL – Geospatial Data Abstraction Library [2] ist heute, am 17.10.2023, 25 Jahre alt geworden. Genau heute, vor 25 Jahren veröffentlichte Frank Warmerdam im CSV-Repository [3] die erste Version.
Der #geoObserver sagt: HERZLICH GLÜCKWUNSCH und Danke Frank, Evenund allen Mitstreitern!
Screenshot: Zeitreise 25 Jahre zurück. Am 17.10.1998 wurde die erste GDAL-Version eingecheckt (Quelle: [3])
Wer im Internet nach dem Mittelpunkt der Hauptstadt Berlin sucht, wird schnell fündig, z. B. beim größten Suchmaschinenbetreiber mit der Abfrage nach „mittelpunkt berlin“ [1]. Ich war am Wochenende in Berlin und Dank des Tipps eines meiner Söhne waren wir vor Ort, am in massiven Granit (?) ausgeführten Stein, wirklich solide gemacht! Auch im OpenStreetMap [2] ist dieser Punkt seit neun Jahren zu finden.
Der „Mittelpunkt“ von Berlin in Kreuzberg, Nähe Alexandrinenstraße 12 (Foto: #geoObserver)
Eine gute Idee, aber der geübte GIS-Blick auf den Stein ließ mich irgendwie zweifeln, rein optisch würde ich den Mittelpunkt eher etwas nördlich und östlich vermuten. Den Anderen ging es ähnlich und im Berlin-Blog [3] finde ich die Bestätigung: „Grundlage war eine offizielle Vermessung, nach unserem Geschmack müsste der Mittelpunkt weiter nördlich sein, aber nun ja, dafür gibt es ja Experten. Vielleicht kennt sich da jemand aus, siehe Kommentarbereich.“ [3] So angepingt bin ich also gleich auf die Suche nach den Geodaten der Berlin-Umrisse gegangen. Gesucht, gefunden [4], im QGIS geladen und das Zentroid prozessiert. Dann mein Foto vom Stein georefenziert und hinterlegt.
Screenshot: Mein QGIS-Test mit dem neuen (?) Zentroid
Und … mein/unser erster optischer Eindruck wurde bestätigt, der berechnete Mittelpunkt liegt eher tatsächlich nördlicher und östtlicher als der auf dem Stein dargestellte. Die Entfernung zwischen beiden beträgt ca. 3000 m! So, und warum nun? Welche Erklärungen könnte es geben?
Angegeben sind am Stein die Berliner Grenzen von 1996, meine geladenen Grenzen [4] sind jünger, angegeben mit ALKIS 03/2023, aber im Sichtvergleich scheinen sie ungefähr die gleiche Geometrie zu haben, also eher nein.
Meine Georeferenzierung ist eher „quick & dirty“, aber rein optisch hinreichend genau
Sind die QGIS-Algorithmen zu ungenau (ich habe mehrere getestet, immer das gleiche Ergebnis) – NEIN: Jetzt noch einmal neu mit FME, SAGA und QGIS überprüft, alle kommen auf den gleichen Zentroiden in der Nähe der Alexandrinenstraße 12 – zum Glück 😉
Die Abbildung auf dem Stein ist nicht ganz exakt? Künstlerische Freiheit oder so? (Mein Favorit)
Wer noch andere Ideen und Erklärungen hat, gern in den Kommentaren, ich bin gespannt …
… die jeder GIS-Analyst kennen sollte. In meinen Schulungen hören die Teilnehmer oft den Satz von mir: „GIS fängt eigentlich erst bei Geoprocessing an, vorher ist nur Gucken“ 😉 In diesem Sinne leite ich Euch heute mal den Artikel „7 Geoprocessing Tools Every GIS Analyst Should Know“ [1], [2] von GISGeography weiter. Danke & 100% Zustimmung! Man muss kein GIS-Guru sein oder werden wollen, es ist grundlegendes Handwerkszeug: Buffer, Clip, Merge, Dissolve, Intersect, Union, Erase. Ich habe genau mit diesen Tools auch 1991 im GIS begonnen, es hat sich quasi an diesem GIS-Fundament nichts geändert.
Auch in unserem KomGIS+ [3] findet Ihr die typischen, grundlegenden Geoprocessing-Funktionen:
Screenshot 2: Geoprocessing-Werkzeuge im KomGIS [3] Screenshot 3: Ausschnitt aus meiner Schulung zum Thema Geoprocessing
Da war er wieder, so ein QGIS-Symbolisierungstipp von SVG* (@newgeographer2) [1], die Gebäude nach der Entfernung zur nächsten Haltestelle visualisieren. Während es SVG mit den Gebäuden und U-Bahn-Stationen in Bangkok gezeigt hat, habe ich das Ganze mal mit den Tram- und Bus-Daten von Halle (Saale) in drei Szenarien simuliert, nur Bus und nur Tram und beides zusammen. Das zentrale Element ist die Visualisierung über den QGIS-Geometriegenerator bei der Symbolisierung über eine Farbkeil „Spectral“ mit einer Distanz bei 400m, zur Verdeutlichung habe ich die 400m-Buffer um die Haltestellen darüber gelegt.
Entscheidend ist die Belegung der Füllfarbe mit einem Ausdruck des Geometriegenerators, z. B. so:
* … SVGs coole Visualisierungs-Tipps sind mitunter recht knapp, ich versuche sie hier etwas besser nachvollziehbar zu testen (Danke auch an @PyQgis für die Unterstützung)
Wer kennt das nicht? Man bekommt Daten und diese werfen plötzlich Fehler. Ursache ist mitunter eine unterschiedliche Anzahl von Geometrie- und Sachdateneinträgen. Das dann händisch zu reparieren geht ganz sicher, kann aber auch mühsam sein. Mit dem Clear Null Geometry-Plugin [1] von Mirjan Ali Sha (@mirjan_ali_sha) kann man schnell Abhilfe schaffen. Hier mein „Selbstversuch“:
Screenshot 1: Das passt nicht zusammen, zwei Geometrien und drei SachdatensätzeScreenshot 2: Der Versuch, den geometrielosen Sachdatensatz 3 anzuzeigen schlägt fehl, es gibt keine Geometrie dazuScreenshot 3: Einsatz des Clear Null Geometry-Plugin und schon ist alles OK, zwei Geometrien und zwei Sachdatensätze
Und wenn Du einen Testdatenbestand sucht, findest Du natürlich keinen. Gut zu wissen, wie man eine solchen erzeugen kann, also unterschiedliche Geometrie- und Sachdateneinträge. In [2] findet Ihr eine Beschreibung, wie Ihr Daten mit Null-Geometrien erzeugen könnt.
Bei Wikipedia heißt es unter dem Suchbegriff „Distanzmatrix“ folgendermaßen: „Die Distanzmatrix ist in der Mathematik eine quadratische Matrix, die die Abstände zwischen Punkten einer Menge angibt“ [1]. Und natürlich gibt es in vielen GI-Systemen eine entsprechende Funktion, im QGIS z. B. entsteht beim Einsatz der Funktion Distanzmatrix ein neues Punkt-Thema mit allen vonPunkt-bisPunkt Einträgen inkl. der Entfernung. Ziel ist es nun, die entstandenen Punktbeziehungen zu topologisch eindeutigen Linien zu verbinden und dabei Hin- und Rückweg zu einer einzelnen Linie zu reduzieren. Ich bin (Quick & Dirty) mit QGIS folgenden Weg begangen:
Distanzmatrix –> Punkte zur Weg –> Linien sprengen (Explode) –> Attribut nach Position verknüpfen –> Auflösen
Hier meine Schritte mit Zwischenergebnissen und das Finale:
Mein Testprojekt inkl. Daten findet Ihr zu Nachnutzung unter QGIS_DistanceMatrix2Lines.zip [2], vielleicht erweitere ich es noch um ein Model. Möglicherweise geht es auch einfacher, wenn ja, gern in den Kommentaren. Ich bin gespannt!
Manchmal sind es die ganz kleinen Dinge, die einem das GIS-Leben erleichtern können. Und diesmal habe ich es im QGIS-Plugin „CIGeoE Converge Lines-Plugin“ [1], [2] gefunden. Dort heißt es, CIGeoE Converge Lines ist ein
„Plugin zum Erstellen eines Konvergenzpunkts von Linien innerhalb eines ausgewählten Bereichs. Dieses Werkzeug sucht innerhalb des ausgewählten Bereichs nach Linienendpunkten, berechnet den Mittelpunkt zwischen diesen Scheitelpunkten und übersetzt die Endpunkte in die durchschnittlichen Punktkoordinaten. Hinweis: Alle Linien mit Start- und Endpunkt innerhalb des ausgewählten Bereichs werden entfernt.“ [2]
Wichtig: Das Plugin funktioniert derzeit „nur“ für Linien-Themen mit Einzel-Geometrien. Ihr müsst also vorher ggf. Polygone in Linien und dann mehrteilige Geometrien in Einteilige umwandeln, also die QGIS-Funktion „Vektor / Geometrie-Werkzeuge / Mehrteilig zu einteilig…“ auf Euer Thema ansetzen. Wenn man damit leben kann, funktioniert das Plugin tadellos. Ich hab es getestet, es klappt prima, nie war es einfacher, quasi mit einem Klick nichttopologische Daten zu topologisch korrekten Daten zu wandeln. Ich würde mir das auch so ähnlich für Polygons und Mehrfachgeometrien wünschen 😉
Nach dem erstaunlichenEcho* 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 der 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).
Screenshot 1: Berechnung der Mittellinie mit der „Skeleton“-Funktion. Die kleinen „Faserstücke“ (Gelb) an den Rändern wurden mittels Selektion (z. B. $length < 40 eleminiert). Übrig blieb die neue Mittellinie (Rot)Screenshot 2: Unterschiedliche Fluss-Mittellinien aus OSM (Blau) und berechnet aus den Ufergrenzen mit der „Skeleton“-Funktion (Grün)Screenshot 3: Ergebnis für die OSM-Variante (Blau)Screenshot 4: Ergebnis für die „Skeleton“-Variante (Grün)Screenshot 5: Ergebnisse für beide Varianten OSM-(Blau) und „Skeleton“ (Grün) mit marginal besseren Ergebnissen bei „Skeleton“Screenshot 6: Die Senkrechten auf der Mittellinie stehen bei „Skeleton“ (Grün) etwas rechtwinkliger zu den Uferlinien
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: