Animation: Mein Test – alle Eingangsthemen, Einstellungen, Ergebnisse
Wer kennt das nicht, man will mehrere Layer gegeneinander verschneiden, aber es stört, immer nur zwei Layer verschneiden zu können, also Thema1 + Thema2 = Ergebnis1, Ergebnis1 + Thema3 = Ergebnis2, … Wie oft hat man sich schon gewünscht, mehrere Layer gleichzeitig zu verschneiden, am besten erst einmal mit UNION, der vollständigsten Verschneidungsfunktion, komplett und ohne Verluste. Abhilfe schafft ganz sicher das neue, am 12.11.2023 veröffentlichte QGIS-Plugin “Multi Union” [1], welches momentan bis zu sechs Themen in einem Schritt verschneidet. Einmal installiert findet Ihr das Plugin in der Toolbox.
Ich habe es getestet, es klappt unter QGIS auf Windows prima, siehe Screenshots:
Unter Mac gibt es momentan leider noch die Einschränkung bzgl. des GDAL-Paketes (momentan ist unter QGIS 3.34.0 nur GEOS-Version 3.9.1 verfügbar, benötigt wird mind. 3.10, ich frage auf der QGIS-Developer-Liste [2] nach).
Screenshot: Fehler auf Mac durch zu alte GEOS-Version
Bereits am 4. November 2023 kam via Tweet die Meldung von Jürgen E. Fischer, dass die Downloads für 3.28.12 “Firenze” and 3.34.0 “Prizren”für Windows und Linux [1] und damit diesmal leider noch nicht für Mac verfügbar sind. Seit vorgestern Abend steht nun zum Glück auch das Mac-Paket zum Download bereit [2]. QGIS 3.34.0 wird mit diesem Release auch zum neuen LTR (LongTermRelease).
Ich habe das neue QGIS-Paket installiert und es läuft erwartungsgemäß hervorragend in meiner GIS-Umgebung, also jetzt QGIS 3.34.0 zusammen mit mittlerweile PostgreSQL v16.1 auf einem MAC mit M1 unter dem inzwischen wieder aktualisiertem macOS 14.1.1 Sonoma, siehe Screenshot. Danke allen Mitwirkenden!!!
Screenshot: QGIS 3.34.0 & PostgreSQL v16.1 auf einem MAC mit M1 unter macOS 14.1.1 SonomaScreenshot 2: Alles wieder OK, das ist es, das QGIS-Paket für Mac (Quelle [2]) 🙂
Stamen war hier schon immer mal wieder ein Thema [1]. In [2] hatte ich bereits am 19. Oktober 2023 über den geplanten Umzug der berühmten Stamen-Hintergrundkacheln berichtet. Der Umzug zu Stadia Maps ist jetzt erfolgreich abgeschlossen [3]. Ich habe es unter QGIS getestet, es klappt wirklich gut, vgl. Animation 1:
Animation 1: Stamen Toner auf Stadia Maps im QGIS getestet.
Was hat sich nun geändert:
Die Kacheln stehen in gewohnter Qualität zur Verfügung, die Performance ist bestens.
Die Kacheln sind allerdings nur noch in deutlich begrenzten Umfang kostenfrei, momentan im Plan „Stadia Free“ mit 200000 Credits/Monat, allerdings scheinen mir diese Credits auch recht schnell verbraucht. Ich habe in zwei Tagen nur mit meinen wenigen Tests schon mehr als 8000 Credits (=1/25 der Monatsmenge) verbraucht. Man muss also sparsam sein!
Der Support ist tatsächlich überragend, ich habe mehrere Anfragen* gestellt, die Hilfestellung war sehr schnell und fachlich fundiert. Danke dafür!
QGIS unter Windows: alles perfekt, QGIS auf Mac: es fehlt immer mal eine Kachel, F5 zum Refresh reicht scheinbar nicht aus, eine Anfrage ist gestellt, ggf. ist es aber auch ein Mac-/QGIS-Problem? Ich suche noch …
Screenshot: In zwei Tagen nur mit wenigen Tests schon mehr als 8000 Credits verbraucht
Screenshot 1: 3D mit dem XYZto3D Plugin rechts. Links nur zur Orientierung das QGIS-View
Selten kommt man mit so wenig Aufwand zu so aussagekräftigen und interaktiven 3D-Modellen! Das QGIS-Plugin “XYZto3D” erwartet ausschließlich Daten aus einer CSV-Datei in der Struktur X, Y, Wert (z. B. Höhe). Eine Visualisierung wie im QGIS-View in Screenshot 1 ist nicht nötig(!), dient hier nur der Orientierung. Installation aus dem Zip-File, Funktion und Bedienung des Plugins sind in “Generate 3D Topography Surface Model from XYZ Data with XYZto3D QGIS Plugin” [2] ausführlich beschrieben. Mein Test mit einem Ausschnitt der Höhendaten der Digitalen Stadtgrundkarte der Stadt Halle (Saale) [3] funktionierte auf Anhieb tadellos.
Screenshot 2: Struktur und Ausschnitt der CSV-Datei Höhendaten der Digitalen Stadtgrundkarte der Stadt Halle (Saale) [3] hier in Libre Office CalcAnimation: Navigieren und Identifizieren im 3D-Ergebnis
Bildvergleich: Zuordnung Berg & Tal am Giebichenstein in Halle (Saale)
Python als Skriptsprache hat insbesondere im Bereich Geografischer Informationssysteme seit Jahren eine wachsende Bedeutung. Sowohl beim Marktführer in der Arc*-Welt wie auch im freien QGIS stehen viele Python-basierte Skripte und Erweiterungen zur Verfügung. Arcpy, PyProj, NumPy sind typische Vertreter. Außerdem können die GI-Systeme mit Python recht einfach um eigene Funktionalitäten und Automaten erweitert werden. In [1] heißt es einleitend:
“Python-Bibliotheken sind die ultimative Erweiterung für GIS, denn sie ermöglichen es Ihnen, die Kernfunktionen zu erweitern. Durch die Verwendung von Python-Bibliotheken können Sie aus der GIS-Schablone ausbrechen und in die Datenwissenschaft eintauchen.” [1]
Früher, zu proprietären (ESRI)-Zeiten hatten wir “clean” für Fehler und “build” für Topologie, die “dangle lenght” und die “fuzzy tolerance”. Etwas Ähnliches findet Ihr in dem neuen QGIS-Plugin “Consolidate Networks” [1]. Coole Sache, so was habe ich schon lange gesucht. Ich habe es mal “quick & dirty” gestestet, es klappt gut, nur eine Frage bleibt (jedenfalls bei mir) noch offen. Vielleicht habt Ihr eine Erklärung, gern in den Kommentaren, den Testdatensatz findet Ihr in [2]. Mein Test, seht selbst:
Screenshot 1: Die Ausgangssituation, Linien mit Digitalisierungs- und TopologiefehlernScreenshot 2: Das Ergebnis, die Linien geometrisch repariert und via FID topologisch verbunden. Nur ein Fehler wird nicht korrigiertScreenshot 3: Meine Test-EInstellungen – alles mal “quick & dirty” mit 20 mScreenshot 4: Das Protokoll des Verarbeitungsprozesses
Im QGIS-Tipp “LineLabels korrigiert” [1] habe ich über die gezielte Beeinflussung von Linienbeschriftungen schon berichtet. Klas Karlson hat Ende September 2023 auf Mastodon [2] eine neues Youtube-Video “QGIS User 0052 – Contour Labels Aggregate function” [3] zur gleichen Thematik angekündigt, mittlerweile ist dieses Video online. Dort wird die Problematik der Linienbeschriftungen noch mal deutlich durch den Einsatz des Geometrie-Generators verfeinert, schaut es Euch an, es lohnt sich. Den verwendeten Code findet Ihr in der Videobeschreibung. Danke Klas!
Via Tweet [1] hat Stamen letzte Woche bekannt gegeben, dass die berühmten Hintergrundkacheln ab 31.10.2023 zu Stadia Maps umziehen. Laut Stamen bleiben die Kacheln “Für die meisten Benutzer immer noch kostenlos” [1]. Mehr Infos findet Ihr bei den Stamen-FAQs [2] und bei Stadia Maps [3]. Ich habe mich mal registriert, im QGIS getestet und werde testen …
Test 1: Die alten Stamen-Kacheln auf Stamen.comTest 2: Die neuen Kacheln bei stadiamaps.com im QGIS (bei mir trotz Anmeldung/API-Key noch mit dem Hinweis)
Über den Neustart des Open Data Portals in Sachsen-Anhalt hatte in “Relaunched: Mehr Open Data im Geodatenportal in Sachsen-Anhalt!” [1] am 04.07.2023 berichtet. Da ich den Sachsen-Anhalt-Viewer mitunter für etwas oversized halte, habe ich mich mal um einen kleineren Viewer bemüht, z. B. um Leuten in meinem Umfeld (Kommunale Verwaltungen und Stadtwerke) auf die Schnelle die typischen freien Daten (ALKIS & Co) mittels der vom LVermGeo LSA angebotenen Geodienste (WMS) zu zeigen. Ihr findet den LSA_OpenData_Viewer unter [2].
Genutzt habe ich QGIS und das qgis2web-Plugin [3]. Alle Themen sind Geodienste aus dem LSA Open Data Portal. Standardmäßig werden Sie vom Plugin als Kachel-Dienste (TileWMS) angelegt. Da Kacheln bei Beschriftungen fast immer schlechte Ergebnisse liefern, denn die Schriften werden an der Kachelgrenzen abgeschnitten, habe ich einige Layer händisch in “normale” WMS-Aufrufe (ImageWMS) umgeschrieben, klappt prima! Hier der Vergleich:
Screenshots: Vergleich von TileWMS (abgeschnittene Schriften) und ImageWMS (nicht abgeschnittene Schriften)
Die Themen nutzen folgende WMS-Typen:
ImageWMS: Bauland, Land- und Forstwirtschaft, Flurstücke, Gebäude, Bodenschätzung
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 …
