Screenshot: Google-Suche nach “Tellurometer” (Quelle [4])
Ich muss zugeben, der Tweet [1] von Massimo (@Rainmaker1973) hat mich angepingt, von einem Tellurometer hatte ich noch nie gehört oder gelesen, aber es ist wohl auch schon ganz lange her, als man begann, diese Geräte zu nutzen. Ich wollte es wissen und Wikipedia [2] sagt dazu:
“Das Tellurometer (lat.-griech.) war das erste erfolgreiche Entfernungsmessgerät auf Mikrowellenbasis. … Das Tellurometer arbeitet mit Mikrowellen, wobei eine Station die Wellen sendet, die ferne Station die Wellen moduliert zurücksendet, so dass man aus der Phasenverschiebung deren Entfernung berechnen kann. Das Instrument kann bei Dunkelheit in Regen und Nebel benutzt werden und reicht für Entfernungen von bis zu 70 km.” [2]
Offensichtlich wurden so 1961 Karten gemacht, hier das komplette Youtube-Video [3], das Tellurometer ab 0:19:
Mehr zur Historie der Geräte erfahrt Ihr in “The History of Tellurometer” [5]. Wieder was dazu gelernt. Hättet Ihr es gewusst und hat gar noch jemand damit gearbeitet? Dann gern in den Kommentaren …
“XPlanung ist ein Datenstandard und Datenaustauschformat und unterstützt den verlustfreien Transfer von Bauleitplänen, Raumordnungsplänen und Landschaftsplänen zwischen unterschiedlichen IT-Systemen sowie die internetgestützte Bereitstellung von Plänen.” [1]
Screenshot: 2011 … 2023 – Es entwickelt sich (Bildquelle [2], [4])
Endlich, das Warten sich gelohnt, für Sachsen-Anhalt gibt es seit April 2023 den “Leitfaden zur Erfassung XPlanungskonformer Bauleitpläne in Sachsen-Anhalt” [2]. Man könnte auch sagen, “Was lange währt wird endlich gut”, “Das Dutzend ist voll.” oder “In der Ruhe liegt die Kraft.” Nun doch etwas länger haben viele Nutzer und Verantwortliche auf ein solches Dokument gewartet, manche Quellen verweisen sogar auf 2005 [3] und 2003 [5]. Ich selbst hatte meine erste Veranstaltung, das Forum XPLanung [4] am 10. März 2011 auf dem Campus in Bernburg, das wäre dann also mein Dutzend 😉 Zwischendurch sollte auch mit XErleben [6] als Prototyp getestet werden.
Hoffen wir, dass das Thema nun wirklich richtig Fahrt aufnimmt, der Standard genutzt und die interkommunale Planung und damit jeder Bürger die Gewinner sind. Danke den Beteiligten: geoGLIS, GFI und der Hochschule Anhalt! Ich gratuliere und hoffe, dass es “endlich gut” wird.
Hier der Original-Tweet [3] – XPlanung wird als “neuer Standard” bezeichnet(?):
Egal, mit welchem GI-System Ihr arbeitet, ob QGIS, ArcGIS, …, die Datenmengen sind bekanntermaßen groß und werden größer. Aber wie können wir sie optimal speichern? Einen Einstieg in die Problematik findet Ihr im Beitrag “Optimizing Geospatial Data Storage” [1] von Harpinder Singh. Im SAN, NAS oder lokal speichern und dabei Skalierbarkeit, Leistung, Redundanz und Kosten berücksichtigen sind Inhalt der Betrachtungen.
GIS-Bücher sind gesucht, hat man sie gefunden, sind sie oft (zu?) teuer. Im Tweet von Luciano Bosso (@BossoLuciano) kam der Tipp: eine Liste kostenfreier GIS-Bücher [2], diesen gebe ich hier gern* an Euch weiter. Es handelt sich zum Teil um vorherige, also etwas ältere Ausgaben, trotzdem sind sie ganz sicher noch lange nicht veraltet und lesenswert. Es lohnt sich!
* … Hinweis: Vorsorglich möchte ich Folgendes mitteilen: Ich gehe davon aus, dass die Quellen legal sind, ich selbst kann das nicht prüfen. Ich hätte aber erwartet, dass sich ansonsten schon einige Twitter-Follower beschwert hätten oder sich in den Kommentaren unter den Büchern entsprechende Hinweise befunden hätten. Meine explizite, positiv beantwortete Nachfrage dazu findet Ihr im Tweet [1].
Laut Wikipedia steht ISO für ‘quantitativ „gleich“ (von altgriechisch ἴσος)’ [1]. Uns begegnen Isolinien im Geoumfeld bei der Datenvisualisierung oft als Höhenlinien. Aber wusstet Ihr eigentlich, wie viele verschiedene Isolinien es gibt? Isochrone, Isobare, Isotherme, … Antwort darauf gibt der Artikel “What Are Isolines?” [3] von Matt Rosenberg. Dort heißt es:
Dies ist eine Liste einiger gebräuchlicher (sowie obskurer) Arten von Isolinien, die auf Karten verwendet werden, um verschiedene Merkmale des Geländes darzustellen, wie z. B. Höhe und Atmosphäre, Entfernungen, Magnetismus und andere visuelle Darstellungen, die auf einer zweidimensionalen Darstellung nicht leicht dargestellt werden können. [3]
Screenshot: Eingebettete QGIS-Karten im Word (Quelle [1])
Stellt Euch vor, Ihr habt die Ergebnisse Eurer Geoarbeiten im QGIS als Karten in Word- und/oder LibreOffice-Dokumenten eingebettet und nun ändern sich jedoch die Inhalte. Es müssten demzufolge alle Eure Karten in allen Dokumenten aktualisiert werden, aber bitte nicht per Hand, sondern automatisch. Im folgendenYoutube-Video “Link to and autoupdate QGIS maps in a Word document” [1] findet Ihr den Workflow dazu. Der Tipp von Anita Graser (@underdarkGIS) [2], Danke!
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).
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:
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: