Kennt Ihr schon wttr.in [1], eine Online-Wetter-Auskunft auf der Kommandozeile, die schnell und präzise mit etwas Vintage-Charme die Wettervorhersage ausschließlich mit Text und die Wettersymbole als ASCII-Art darstellt. Mit Curl direkt auf der Konsole (im Terminal) zur nutzen. Der Aufruf im Browser https://wttr.in/ oder https://wttr.in/”Halle (Saale)”. Eine sehr große Zahl von Parametern steht zur Verfügung, die Hilfe dazu könnt Ihr mit https://wttr.in/:help [5] aufrufen.
Screenshot 1: Standardausgabe mit akt. Wetter und Voraussage für drei TageScreenshot 2: Reduzierte Ausgabe
Nun wollte ich dan Ganze mal direkt im QGIS nutzen, einfach eine kleine Karte mit der Tooltipp-Funktion (“Kartenhinweise anzeigen”) via HTML, hier die einfache Darstellung für das aktuelle Wetter im iFame auf die Spalte “ort” im Datenbestand. Klappt, na bitte … Sicher gibt es genügend andere und elegantere Möglichkeiten, Wetterdaten ins QGIS zu holen, aber mit wttr.in wollte ich es auch mal probieren 😉
Screenshot 3: Einbindung ins QGISScreenshot 4: Nutzung im QGISScreenshot 5: Nutzung im QGIS animiert
3D-Print von Geodaten ist nun schon oft beschrieben worden, das hat viel Potenzial, wirklich neu ist es nicht mehr. Eine interessante Idee hatten nun Studierende der Harvard Graduate School of Design und des Harvard College und diese haben sie dann auch realisiert: Geodaten in 3D-Schokolade, ChopcoTopo eben! Genutzt haben sie die klassischen 3D-Informnation beinhaltenden Daten, DEM und Satellitenbilder mit Höhen. Genutzt wurde auch QGIS, dann 3D-Negativ-Formen gedruckt, Schokolade rein, kalt werden lassen und … fertig! Geo-Daten mit Geschmack hatten wir übrigens schon mehrmals [3], [4] 😉 Ich hoffe, damit nun endlich auch den letzten invasiv-Excel-nutzenden GIS-/Geo-Verweigerer mit dieser Schokolade ins GIS-Boot zu bekommen, was meint Ihr?
Mit Geoapify [1] steht eine weitere API als Google-Alternative im Geobereich zur Verfügung. Es kann sich durchaus lohnen, dort mal nachzuschauen, denn schon in der FREE-Variante stehen Euch bis zu je 3000 Geocoding-, Place-, Routing- und Isolines-Requests zur Verfügung.
Zu den Daten wird auf der geocodig-api-Seite [3] folgendes gesagt: “Die Geokodierungs-API arbeitet mit internationalen Adressen und liefert Ergebnisse in einer bestimmten Sprache. Wir verwenden mehrere Datensätze, darunter OpenStreetMap, OpenAddresses, Who’s on First, Geonames, Wikipedia und weitere. Die benutzerdefinierten Datensätze können auf Anfrage importiert werden.”
Mein erster Test mit Geocoding [2] war erfolgreich, siehe unten:
Vorgestern gab es via bei Twitter folgende Anfrage: “Ich möchte mithilfe des Geometriegenerators den Zentroid eines aus einem Punktdatensatz (7 Punkte) erstellten Polygon mit einem noch nicht definierten Abstand puffern und dies als “Lage im Raum” darstellen.” [1]. Wie man das mit “normalen” Geoprocessing-Funktionen des QGIS lösen kann, eher kein Problem, aber dann entstehen ggf. immer wieder zusätzliche Layer. Die Forderung war ja, es mit dem Geometrie-Generator zu lösen. Unser Interesse war geweckt, wir wollten es wissen. Eigentlich auch nicht schwierig, nur konnte ich QGIS erstmal nicht überreden, die Punkte als gemeinsame Geometrie zu betrachten, QGIS wollte das immer für jeden Punkt einzeln tun. Die entscheidende Idee hatte dann mein Kollege mit “arrray_foreach” und “aggregate”, der Rest drum herum war ja schon fertig.
Wer den Code verbessern möchte, gern hier als Kommentar. Wir sind gespannt!
Mehrere Punkte hinzufügen und löschen, Konvexe Hülle, deren Centroid und der Buffer um diesen passen sich an
PerMail [1] gab Even Rouault gestern bekannt, dass seit dem 07.09.2021 eine neue Version der universellen GDAL-Bibliothek [2] zur Verfügung steht. GDAL ist vor allem als Kommandozeilen-Tool, aber auch als wesentlicher Bestandteil von QGIS bekannt ist. Die Neuerungen findet Ihr auf GitHub [3], die Downloads bei GDAL [4] und OSGEO [5].
Zum 13. Geofachtag des netzwerk | GIS Sachsen-Anhalt durfte ich den Vortrag “Open Data in HAL – ein Praxisbericht aus Halle (Saale)” halten. Da mittlerweile immer mehr Anfragen bei mir ankommen, stelle ich den Vortrag hiermit gern als Download zur Verfügung.
Wolltet Ihr auch schon immer mal wissen, wie viele Dezimalstellen man für Längen- und Breitengrade braucht, um eine ausreichende Genauigkeit zu realisieren? In “Latitude and longitude precision” auf observablehq.com findet Ihr anschaulich die Auflösung [1], [2]. Es sind übrigens weniger, als man denkt.
Screenshoots animiert (Quelle [1])
Das Frage ist übrigens nicht ganz neu, die wohl beste Analyse, die ich kenne findet Ihr auf im Webcomic “Coordinate Precision” auf xkcd.com: Mach es nur genau genug und Du kannst die Position eines Atoms angeben 😉
🌐 How many decimal digits do you need for longitude and latitude? Not as many as you think. Visualized on this @observablehq notebook: https://t.co/6AwWMGck5G
(So, der Urlaub ist vorbei, es geht wieder los beim #geoObserver 😉 Das ist wirklich genial! Und interessant und kurzweilig und faszinierend! Stell Dir vor, Du kannst irgendwo einen Regentropfen fallen lassen und eine mit vielen Geoprocessing-Features ausgestattete, webbasierte Anwendung zeigt Dir dreidimensional animiert den Weg des kleinen Tropfens bis zum Meer. So gesehen beim River-Runner [1] von Sam Learner [2] (@sam_learner [3]). Leider monentan nur für das Gebiet der USA. Mein erster Test: ein Regentropfen in Buffalo (WY) [4].
Screenshots: Von Buffalo (WY) zum Golf von Mexico (Quelle [1])
Zur Erinnerung: heute ist Anmeldeschluss für den 13. Geofachtag des netzwerk | GIS am 01.09.2021. Also los, schnell noch anmelden! Und Ihr wisst ja: die Anmeldung ist kostenlos!
Ja, das haben wir wohl alle so gelernt, der Petersberg sei die höchste Erhebung vom Harz bis zum Ural auf diesem Breitengrad? Und neulich sprach mich ein Bekannter an, er hätte es mal mit diversen Programmen aus dem Outdoor-Bereich überprüft und es wäre wohl nicht so. Ich habe sofort recherchiert und bin zuerst im Wikipedia fündig geworden, tatsächlich, die o. g. Aussage ist wohl tatsächlich falsch: “Entgegen einer weit verbreiteten Meinung ist der Berg etwa auf seinem Breitengrad nicht die höchste Erhebung zwischen dem Harz und dem Uralgebirge” [1].
Nun war aber meine Neugier geweckt, schließlich haben wir ja GI-Systeme, am liebsten QGIS. Und ein paar Viertelstunden später hat auch QGIS es bestätigt: Der Petersberg ist NICHT die höchste Umgebung bis zum Ural auf diesem Breitengrad!
Meine Herangehensweise:
Ural- und Harz-Umrisse sowie 5 Grad-Gitter besorgen [2],[3], [4]
SRTM-Kacheln mit dem QGIS-Plugin SRTM-Downloader einladen [5] und daraus eine VRT zur einheitlichen Symbolisierung machen
mittels eines einfachen händisch erstellten GeoJSON-Files (in [7] enthalten) den Petersberg-Breitengrad erstellt
via SAGA-Funktion “Profile from Lines” die Profildaten erzeugt (180000 Punkte)
Der Rest war dann einfache Symbolisierung im QGIS
Screenshot: GeoJSON für Petersberg-Breitengrad (in [7] enthalten). Zwei Punkte reichen für das rechtwinklige Koordinatensystem, ansonsten können mit QGIS-Bordmitteln (PointsAlongLines, PointsToPath) noch Zwischenpunkte erzeugt werden Screenshot: Der komplette Verlauf auf dem Petersberg-Breitengrad vom Harz zum Ural mit den Erhebungen Screenshot: Die erste Erhöhung weit westlich vor dem Ural Screenshot: Die in [1] erwähnten Erhebungen in Polen [8] liegen nicht direkt auf dem Petersberg-Breitengrad (hier ca. 24 km Abweichung bezogen auf vorhandene Peak-Höhen im OSM-Datenbestand)
Zum Nachvollziehen hier mein Testprojekt [7] (ohne STRM-Daten, die könnt Ihr Euch bei Bedarf ja selbst mit [5] runter laden).
