Seit Freitag, dem 05.06.2026, ist eine neue Version des QGIS-Plugins „GeoBasis_Loader“ [1] verfügbar: v2.1.1 [2]. Diese Version ist ein Bugfix-Release für v2.1 [3]. Was wurde behoben?
Installationsproblem bei Neuinstallationen: In Einzelfällen konnten nach einer komplett neuen QGIS-Installation die Kataloge nicht gelesen werden (bei rund 1750 Downloads wurde das Problem nur zweimal gemeldet – aber eben zweimal zu viel).
Protokollierungs-Problem: Eine fehlerhafte Logging-Ausgabe bei Netzwerkfehlern wurde korrigiert.
Bitte aktualisiert in Eurem QGIS das Plugin zeitnah auf den neuen GeoBasis_Loader v2.1.1, damit Ihr von den Fixes profitieren könnt. Vielen Dank an die User, die den Fehler gemeldet haben und ein Dankeschön an Anton & Thomas für das schnelle Beheben!
Seit Freitag, dem 29.05.2026, um 12:05 Uhr ist eine neue Version des QGIS-Plugins „GeoBasis_Loader“ [1], aktuell v2.1. Was ist neu? 1. Zuwachs im GBL-Team: Nachdem bislang Anton May die Programmierung verantwortet hat und ich das Projekt als Maintainer sowie als Erfasser der inzwischen 846 Geodienste betreue, freuen wir uns, seit März mit Thomas Wölk einen weiteren Entwickler im GBL-Team begrüßen zu dürfen. Und natürlich 2. Neue Features: Neben umfangreichem Code-Refactoring bringt die neue Version vor allem inhaltlich einige Neuerungen mit sich – konkret wurden folgende Funktionen ergänzt:
1. Werkzeug/Button Neben der Steuerung über das Erweiterungs-Menü gibt es den „GeoBasis_Loader“ jetzt auch mit einem Werkzeug/Button, an dem das gleiche Menü angehängt ist
Screenshot 1: Der neue Button des GBL in der Werkzeugleiste
2. Favoriten Unter Favoriten kann der Nutzer jetzt seine persönlich bevorzugten Themen einstellen und so jederzeit ganz schnell auf diese zugreifen.
Screenshot 2: Die neuen GBL-Favoriten
3. Presets (Zusammenstellungen) Mit den Zusammenstellungen können persönliche Gruppen von Themen gespeichert und verwaltet werden, z. B. Alle Schutzgebietsdaten (NSG, LSG, P30-Biotpe, GLB, FND) oder alle Daten der Flüsse (Bundeswasserstraßen, PegelOnline-Daten), …
Screenshot 3: Die neuen GBL-Presets, der Tooltip zeigt auch gleich die enthaltenen Themen an
Bei Bedarf kann zur jedem Preset auch auch ein räumliches Lesezeichen gespeichert und genutzt werden. Diese Lesezeichen steht dann auch im QGIS-Browser als Benutzerlesezeichen in der Rubrik „GeoBasis_Loader“ zur Verfügung.
Screenshot 3b: Die räumlichen Lesezeichen für GBL-Presets
4. Kontextmenü für alle Themen zum Handling der Favoriten, Presets, Ein- und Ausblenden, Aktivieren und Deaktivieren
Screenshot 4: Das neue GBL-Kontextmenü – rechte Maustaste auf jedem Thema
Das Geo-Wochenende ist gerettet 😉 Ich hatte über das Thema, wie aus LIDAR-Daten wunderschöne Karten, fast schon Kunst werden, bereits zweimal berichtet, vgl. [1] und [2]. Faszinierend sind diese Karten für mich immer noch. Nun bin ich auf ein Youtube-Tutorial [3] gestoßen, was die Erstellung von REM-Karten mit Lidar-Daten in R beschreibt, hochinteressant, quasi DataViz par excellence! Übrigens, den vollständigen Code gibt’s auf GitHub [5], die LIDAR-Daten bei der USGS [6].
Wenn man mal ganz schnell einen Plan braucht und vielleicht das gewohnte GI-System gerade nicht verfügbar ist, dann lohnt es sich, mal bei der Plantaube [1] von Julian Lindner [2] vorbei zu schauen. Mit wirklich wenigen Klicks und Eingaben könnt Ihr einen Plan erstellen und in verschiedenen Formaten exportieren. Ich habe es mal ausprobiert und es funktioniert absolut problemlos. Aus meiner Sicht sind vor allem die einfache Bedienung und die sehenswerte Plangrafik hervorzuheben. Mein Ergebnis-PDF findet Ihr unter [3]. IMHO: Coole Lösung! Genutzt werden selbstverständlich die OpenStreetMap-Daten.
Das Projekt ist noch im Entstehen, um Feedback wird ausdrücklich gebeten. Ich würde mir noch bessere Beschriftungsmöglichkeiten, den verpflichtenden Hinweis auf OSM-Daten im PDF und vielleicht die Einbindung eigener Daten wünschen, aber ich bin mir sicher, dass kommt bestimmt noch, ich habe schon angefragt.
Screenshot 1: Die Adresse suchen, hier Halle, Ankerstraße 3b, Maßstab, Papierformat und -Orientierung sowie Himmelsrichtung wählenScreenshot 2: Opetionen Einstellen, hier z. B. die Schatten für Gebäude und BäumScreenshot 3: PDF generieren lassen
Screenshot 1: Der VeganGuide [1] weltweit, auffällig der besonders hohe Anteil in Europa und die verschwindend kleine Anzahl in der Antarktis 😉 (Bildquelle [1])
Der VeganGuide [1] ist eine auf OpenStreetMap (OSM) basierende Karte, die Euch das Finden veganer und/oder vegetarischer Restaurants, Imbisse und FastFood-Lokationen erleichtert. Momentan, also mit Stand heute, den 20.05.2026, 00:06 Uhr zeigt diese Karte alle im OSM erfassten und entsprechend getaggten 49.579 veganen Lokale in 167 Ländern. Unterschieden wird nach Kategorien wie „vegan“, „vegan options“ und „limited vegan options“ je nach veganem bzw. vegetarischem Anteil. Ich habe es mal für Halle (Saale) getestet, an einer Stelle, die ich ganz gut kenne, am Reileck [2].
Screenshot 2: Die Situation in Halle (Saale), am Reileck [2] gleich zwei vegane Lokationen in unmittelbarer Nähe (Bildquelle [2])
Coole Geschichte, ich würde mir vielleicht doch eine etwas deutlichere Unterscheidung bei den Kategorien in der Karte wünschen. Die Anwendung ist Open Source, den Code findet Ihr auf Codeberg [3]. Weiter Infos zum Thema Vegan/Vegetarisch via OSM-Daten findet Ihr unter [4] und [5].
Am 7. Mai 2026 fand das Webinar „Geobasisdaten & Kartenerstellung“ [1] der Firma NTI zusammen mit dem #geoObserver statt. Seit einigen Tagen ist die Webinar-Aufzeichnung auf Youtube [2] online. Wer also nicht mit den mehr als 180 Teilnehmern live dabei sein konnte, kann sich ggf. noch einmal via diesem Mitschnitt informieren.
Neben der aktuellen Version v2.0.0 des GeoBasis_Loaders [3] stellte ich auch erstmalig neue und geplante Funktionen für v2.1 und 2.2 als Prototyp vor. Im zweiten Teil zeigte NTI-Fachkollege Jakob Wilhelm, wie im QGIS mit den wunderbaren freien und nun auch via GeoBasis_Loader einfach geladenen Daten eine Karte erstellt werden kann.
Video: QGIS- & GeoBasis_Loader-Webinar – Der Mitschnitt
Wenn Du mal ganz schnell ein 3D-Modell eines Planungsgebietes brauchst, kann Dir ganz sicher Map3D[2], [3] weiterhelfen. Dort heißt es:
„Dies ist ein 3D-Gebäudekartierungsdienst, der mit React-Three-Fiber implementiert wurde. Er ermöglicht den Export als GLB-Datei und alle Funktionen sind kostenlos nutzbar. Auf diesem Projekt aufbauend lassen sich verschiedene Funktionalitäten wie digitale Zwillinge, Drohnenvermessungen und GPS-Markierungen realisieren.
Die Kartendateien basieren auf OpenStreetMap-Daten.“ [2]
Auf der Webseite des Projektes [2] kann man die Funktionsweise testen, ich habe es mal probiert, es funktioniert wunderbar. Noch nie bin ich einfacher zu (m)einem 3D-Modell gekommen. Man braucht nur folgende fünf Schritte auszuführen:
Schritt 1: In das gewünschte Gebiete bewegen/zoomenSchritt 2: Zu berechnenden Ausschnitt markierenSchritt 3: kurz rechnen lassenSchritt 4: Ergebnis der Berechnung Schritt 5: Das fertige 3D-Modell
Momentan sind realisiert: 3D-Gebäude erstellen, Straßen bauen und GLB exportieren. In Zukunft soll es noch mehr geben: Gebäudestruktur, Höhenanpassung, Material und Höhenkarte. Ihr findet den Quellcode und noch weitere Details auf GitHub [2].
Hier der Original-Tweet [1]:
Someone open sourced a tool that generates a full 3D model of any city on Earth in seconds real buildings, roads, elevations, exportable as GLB for Unity, Blender, AR, or drones.
Letzte Erinnerung! Heute, 10:00 Uhr findet das Webinar „Geobasisdaten & Kartenerstellung“[1] der Firma NTI zusammen mit dem #geoObserver statt. Dort zeige ich im ersten Teil das QGIS-Plugin „GeoBasis_Loader“ [2] in Funktion. Außerdem werde ich auch einige neue und geplante Funktionen als Prototyp vorstellen. Im zweiten Teil zeigt ein NTI-Fachkollege, wie im QGIS mit den wunderbaren freien und nun auch via GeoBasis_Loader einfach geladenen Daten eine Karte erstellt werden kann. Das Webinar ist kostenlos, eine Anmeldung ist auch heute noch unter [1] ist möglich.
Also heute: 7. Mai 2026, 10:00 Uhr – 11:00 Uhr
In meinem Teil dürft Ihr Euch konkret auf folgende Informationen zum GeoBasis_Loader in der aktuellen Version freuen:
Vorführung ausgewählter typischer Funktionen
Zweck und Anspruch
Historie und Team
Kataloge und Datenhaltung
Nutzungsbedingungen
Status, Meldungen, FAQs und Videos auf der Webseite geobasisloader.de [2]
Newsletter, Sponsoring und Möglichkeiten zur Mitwirkung
Ausblick und quasi „Weltpremiere“ 😉 Vorschau auf den Prototypen für v2.2
Installation
Screenshot: Vorschau auf den Prototypen für v2.2 mit Panel für Kataloge, Favoriten, Presets und Einstellungen
Seit der letzten GBL-Meldung [1] sind weitere 55 neue Themen in den Katalogen des QGIS-Plugins „GeoBasis_Loader“ (GBL) [2] hinzu gekommen. Dabei handelt es sich um:
30 Themen der Kommunalen Wärmeplanung Halle (Saale) als WMS
6 Themen Verwaltungsgrenzen 1:25000 (WFS)
15 Themen zu sächsischen Höhendaten (WFS)
2 Themen zur Flurbereinigung in BW
2 Themen für BRW 2026 in ST (WFS)
Aktualisiert wurden gleichzeitig:
ALKIS, BRW in BE
AP 10 in NI (WFS)
Damit stehen mit Stand heute 835 Themen im GeoBasis_Loader zur Verfügung. Den aktuellen Stand findet Ihr übrigens immer live im Status [3] und bei der Meldungen [4].. Danke allen Zuarbeitenden 🙂
ALKIS Berlin: Ein Darstellungslayer vs. 5 Sachdatenlayer in einem WMS, warum?
Also eigentlich dachte ich, ich kenne mich mit OGC-konformen Geodiensten ganz gut aus. Nun bin ich aber in Berlin (IMHO ein echter Open Data Vorreiter!) auf einen im März 2026 aktualisierten ALKIS-WMS [1] gestoßen, den ich in dieser Form noch nicht erlebt habe und eigentlich so auch nicht verstehe. Warum betreibt man einen WMS anders als vom Standard vorgesehen?
Ein WMS zeichnet sich lt. Wikipedia durch folgenden Eigenschaften aus:
„Im Sinne eines verteilten Geoinformationssystems (GIS) besitzt ein WMS nur die Fähigkeit zur Auskunft der notwendigen Metainformation, zur Visualisierung dieser Geodaten und für eine allgemeine Abfrage der zugrundeliegenden Sachdaten.“ [2]
Bekanntermaßen liefert mir ein WMS eine Karte mit GetMap (ein georeferenziertes Bild als PNG, GIF, JPG, TIFF, …) und gleichzeitig auf Anfrage die Sachdaten eines Objektes über einen abgefragten Punkt (Koordinate) in diesem Dienst mit GetFeatureInfo. Des Weiteren können noch die Legende mit GetLegendGraphic und die Eigenschaften mit GetCapabilities abgefragt werden.
In Berlin macht man es nun aber plötzlich anders. Hier werden die Inhalte zur Visualisierung für die Flurstücke, Gebäude, Bauwerke, … in einem Layer gemischt und die Sachdaten getrennt in weiteren fünf Layern, immerhin alles in einem Dienst vorgehalten, einer für die gemischte Karte (GetMap) und die fünf für die Sachdaten (GetFeatureInfo). Aber warum? Das heißt ja für den Nutzer in seinem GI-System immer mindestens zwei Layer laden, einen mit der Karte ohne Sachdaten, um die Geodaten überhaupt zu sehen und den zweiten, eben mit leerer Karte, nur, um die Sachdaten via Identifikation abfragen zu können. Das bringt
die Nutzer durcheinander,
erhört den Aufwand,
senkt die Transparenz,
konterkariert IMHO die WMS-Philosophie und
ist doch eigentlich total unnötig, oder?
Ich hätte je einen Layer für Flurstücke, einen für Gebäude, Bauwerk, Nutzung, etc. erwartet, jeweils mit Karte und Sachdaten, so wie üblich und in allen anderen Bundesländern auch realisiert, üblicherweise getrennt nach Flurstücken, Gebäuden und tatsächlicher Nutzung. Für GIS-Insider ist das vielleicht gewöhnungsbedürftig, aber machbar, für „normale“ Endkunden ohne spezielle GIS-Kenntnisse im WebGIS wie OpenLayers, Leaflet oder MapLibre eine Zumutung.
Hier die Problematik für das Thema „Flurstücke“ mal bebildert:
Screenshot 1: Die zwei verschiedenen Layer für die gemischte „Darstellung“ und die Flurstücks-„Sachdaten“ im QGISScreenshot 2: Nur der Layer für „Darstellung“ leider ohne IdentifikationsmöglichkeitScreenshot 3: Nur der Flurstücks-Layer für „Sachdaten“ leider ohne KarteScreenshot 4: Nur der Flurstücks-Layer für „Sachdaten“ identifizierbar aber leider ohne KarteScreenshot 5: Beide Layer für gemischte „Darstellung“ und Flurstücks „Sachdaten“ und nur bei richtiger Aktivierung (blau) auch mit Identifikationsergebnis
Ich habe mich mit einigen Fachkollegen dazu ausgetauscht, keiner hatte eine Idee oder plausible Erklärung. Und was macht man heute, man befragt die KI, meinen Chat dazu findet Ihr in [3]. Aber auch dort bin ich nicht wirklich fündig geworden. Der noch plausibelste Grund für verschiedene Toleranzen sollte bei Flurstücken, Gebäuden, … eher keine Rolle spielen, diese Objekte trifft man per Mausklick im Allgemeinen immer sicher.
Vielleicht können uns die Berliner Kollegen mal auf die Sprünge helfen, warum sie das so (ungewöhnlich) gelöst haben, gern in den Kommentaren. Ich jedenfalls bin gespannt und lerne gern dazu!
Übrigens, über den für mich unverständlichen, weil unterschiedlichen Umgang mit inhaltlich gleichen Themen in den einzelnen Bundesländern habe ich in meinem Vortrag „Open Data in D: Perfekte Idee, halbherzige Umsetzung? Ein Erfahrungsbericht.“ auf der FOSSGIS 2025 in München [4], [5] das erste Mal berichtet, dann immer mal wieder.
