Einen coolen Tipp für die Beschleunigung von DB-Abfragen in der PostgreSQL-Datenbank habe ich die Tage im Artikel „PostGIS Performance: Data Sampling“ [1], [2] von Paul Ramsey gefunden. Bei Tabellen mit sehr großen Datenmengen können die Abfragen recht lange dauern, mitunter braucht man aber nur gute Näherungen und Stichproben liefern ausreichend genaue Ergebnisse. Es kann also reichen, z. B. nur ein Prozent der Gesamtheit abzufragen und dabei ein ziemlich gutes Stichproben-Ergebnis zu bekommen, aber viel (Abfrage-)Zeit zu sparen. Es hilft das „Gesetz der großen Zahlen“ [3]. Für die PostgreSQL-DB lautet das Zauberwort:
TABLESAMPLE SYSTEM | BERNOULLI
Ich war mal neugierig, hier mein ganz einfacher Test:
Mein Test: Abfragedauer über alle Datensätze und dann nur 10% und 1%
Wir setzen den MapServer bereits seit 2001 im KomGIS+ Vorgänger/Prototypen GIS+ und HALgis erfolgreich ein und sind ihm zusammen im KomGIS+ [6], HALgis [7] und dem halleschen Open Data Portal [8] bis heute treu geblieben. Danke alle Mitwirkenden, Großartig!
Georeferenzierung ist mit QGIS an sich kein Problem, aber es kann mitunter zeit- und nervenraubend sein. Was liegt also näher, als im Zeitalter der Künstlichen Intelligenz genau diese auch die Georeferenzierungs-Arbeit machen zu lassen. Die beiden Tweets [1], [2] zeigen eindrucksvoll die Möglichkeiten und die IMHO beeindruckende Präzision. Alles realisiert mit dem QGIS-Plugin „Bunting Labs AI Vectorizer“ [3].
The AI Georeferencer in QGIS is now publicly available
1. Aerial imagery georeferences to satellite near the QGIS map canvas 2. The full georeferencer reads coordinates, buildings, streets, PLSS, cities, and other features humans use
PS: Ich habe es noch nicht selbst getestet, es steht aber auf meiner ToDo-Liste. Wenn schon jemand Erfahrungen mit dem Plugin gemacht hat, lasst uns bitte in den Kommentaren daran teilhaben. Danke!
Screenshot: Meine aktualisierte GIS-Umgebung auf Mac M1
Es stand seit einiger Zeit an, gestern Abend habe ich mich endlich mal ran gesetzt und alle aktuellen Komponenten auf meinem Mac installiert. Meine neue GIS-Umgebung, also jetzt:
QGIS 3.99.0-Master mit Qt6 (Test für QGIS v4)
PostgreSQL v18.1 inkl. PostGIS 3.6.1 via Postgres.app 2.9.2
macOS 26.1 „Tahoe“
alles auf einem MAC mit M1
Es war wie immer unkompliziert und läuft erwartungsgemäß hervorragend, Danke allen Mitwirkenden!!!
Einen coolen Plugin-Tipp bekam ich die Tage von Ingo Michalak, einem Bekannten aus der Halleschen Geobubble. Er hat das QGIS-Plugin „Project Packager“ [1] getestet und ist recht angetan. Sein Praxisbeispiel war die Weitergabe eines QGIS-Projektes mit Daten der Römischen Straßen [2], welches ich vor kurzem vorgestellt habe. Hier seine Erfahrungen mit dem Plugin, ein gutes Kochbuch mit Hinweisen auf Fallstricke, Es folgt O-Ton Ingo M.:
Jeder kennt’s vermutlich: man hat ein historisch gewachsenes Projekt gebastelt mit Daten aus verschiedenen lokalen Quellen und nun will man es „mal eben“ an einen Kollegen (oder Auftraggeber) übermitteln oder man will es einfach nur archivieren und fängt an alle Daten zusammen zu sammeln und die Datenquellen im Projekt neu zuzuweisen. Mit dem folgenden PlugIn ist das kein Problem mehr!
Für die Vorbereitung der Daten zur Übermittlung oder Archivierung den Project Packager installieren:
Dann das Projekt noch mal abspeichern (zwingend nötig für das Plugin, ungespeicherte Änderungen kann es nicht handhaben) und den Packager starten.
Dann einen Ziel-Ordner auswählen (hier darf nicht derjenige Ordner ausgewählt werden, in dem das bisherige Projekt liegt). Ich empfehle unter Data storage options die unteren beiden Optionen auszuwählen:
Dann erhält man nämlich ein einzelnes GeoPackage, in dem auch das Projekt selbst enthalten ist.
Wenn man das GeoPackage dann im QGIS-Browser öffnet, sieht man neben den Geodaten auch das Projekt, das man so direkt aus QGIS heraus öffnen kann und alles sieht beim Empfänger so aus wie beim Absender.
Zwei wichtige Einschränkungen: 1) Daten, die als Link im Projekt sind, bleiben Link. Bei WMS ist das klar, bei WFS kein Problem. Bei Daten, die in lokalen Datenbanken liegen (PostGIS-Server auf dem localhost z.B.), sind diese beim Empfänger anschließend nicht verfügbar. Solche Daten müssen also zuerst über irgendein Dateiformat lokal abgelegt und ins Projekt integriert werden.
2) Große Rasterdaten machen dem Plugin offenbar Probleme (diese sind in GeoPackages eh eher unhandlich). Sie sollten also ggf. vor der Anwendung des PlugIns aus dem Projekt entfernt und separat übermittelt werden.
Danke Ingo! Übrigens, das fertige vom QGIS-Plugin „Project Packager“ exportierte GeoPackage findet Ihr unter [3]. Mein Test mit diesem Export klappt bestens, vgl. folgenden Screenshot 🙂
Bereits im Oktober wurde die bekannte Open Source Routing Machine “GraphHopper” [1] auf die Version 11.0 [2] aktualisiert. Jede Menge Verbesserungen und Neuigkeiten erwarten uns, Schwerpunkte bilden z. B. Abbiegehinweise, Fahrradverbesserungen, Flexible Umschlagkosten (Vermeidung von Linksabbiegen), verbesserte Vermeidung von Privatstraßen und Leistungserhöhung bei der Isochronenberechnung, den Routing-Abfragen und beim Importprozess.
Manchmal können auch die ganz kleinen Tools viel GIS-Freude bereiten. Neulich hatte ich das Problem 2,9*10E-5 Bogensekunden für den Bereich Halle (Saale) in Meter umzurechnen. Ein Tipp vom Kollegen: Arc2Meters [1] auf OpenDem. Probiert und klappt, hier mein realer Test:
2,9*10E-5 Bogensekunden (1) bei 51,5 Grad (2) entspricht ca. 0,5 mm (3)
Animation: Donut-Polygon-Generierung mit KomGIS+ via ERASE
Donut-Polygone, mitunter auch als Kreisringlöcher oder Inselpolygone bezeichnet, werden im GIS immer wieder gebraucht, z. B. dann, wenn eine Fläche ein Gebiet nicht vollständig, sondern auch eine Insel oder ein Loch enthält. In einigen GI-Systemen gibt es dafür spezielle Werkzeuge, in manchen, z. B. unserem KomGIS+ nicht. Aber es braucht sie auch nicht zwangsläufig, da man auch mit den ganz normalen Geoprocessing-Funktionen solche Polygone erzeugen kann. Praxisbeispiel war ein Nutzeranfrage: „Ich brauche alle Flurstücke einer Gemarkung, aber ohne die darin liegende Dorflage“. Wie es gelöst werden, wird in den folgenden drei Schritten gezeigt:
Schritt 1: Erzeugen/Beschaffen des Aussenpolygons (z. B. die Gemarkung)
Schritt 2: Erzeugen/Beschaffen des Insel- oder Lochpolygons (z. B. die Dorflage)
Schritt 3: Ermittlung des Donut-Polygons durch Geoprozessing mit der ERASE-Funktion (Gemarkung minus Dorflage)
Schritt 4: Berechnung der Zielflurstücke mittels Geoprozessing via CLIP-Funktion (Flurstücke gegen Donut-Polygon)
Screenshot 1: Geoprozessing mit ERASE – PrinzipdarstellungScreenshot 2: Ausgangssituation – Die Flurstücke im BearbeitungsgebietScreenshot 3: Schritt 1 – Erfassen des AussenpolygonsScreenshot 4: Schritt 2 – Erfassen des Insel/LochpolygonsScreenshot 5: Schritt 3 – Geoprozessing mit ERASE – Löschen des Loches aus dem Aussenpolygon – Ergebnis ist das Donut-PolygonScreenshot 6: Schritt 4 – Geoprozessing mit CLIP – „Ausstanzen“ der Flurstücke mit dem Donut-Polygon als „Maske“Screenshot 7: Ansicht des finalen Ergebnisses Flurstücke mit Insel/Loch ohne weitere Layer
Vier Tage nach dem letzten Update [1] gab GDAL-Maintainer Even Rouault vorgestern, am Samstag, den 08.11.2025 per Mail [2] bekannt, dass eine neue Version der universellen GDAL-Bibliothek [3] zur Verfügung steht, aktuell ist nun GDAL v3.12.0 ein Feature Release. GDAL steht für Geospatial Data Abstraction Library und ist vor allem als Kommandozeilen-Tool, aber auch als wesentlicher Bestandteil von QGIS bekannt. Die Neuerungen findet Ihr auf GitHub [4].
GDAL [1] als ultimative Geo-Konvertierungs-Bibliothek dürften die meisten ganz sicher kennen und nicht umsonst ist GDAL wesentlicher Bestandteil vieler GI-Systeme. Aber wusstet Ihr, dass man mit GDAL auch geoprozessieren kann. Neulich las ich dazu auf LinkedIn einen Beitrag zur Berechnung von Rasterzonalen Statistiken [2] von Krzysztof Dyba [3]. Man nehme also Rasterdaten und einen Vektordatenbestand, z. B. Stadtteile und kann mit GDAL beispielsweise den Mittelwert aller Pixel des Rasters in den Stadtteilgrenzen berechnen lassen. Wunderbar für automatisierte Prozesse. Alle Details findet Ihr in der GDAL-Dokumentation [4].
