QGIS automatisieren: 1 Aufgabe, 4 Methoden, gemessen an 2 Städten

Einen wiederkehrenden QGIS-Workflow können Sie auf vier Arten automatisieren: mit der Stapelverarbeitung für ein Werkzeug über viele Dateien, mit dem Graphical Modeler (Grafische Modellierung) für eine Werkzeugkette, die Sie erneut ausführen, mit einem PyQGIS-Skript für Schleifen und exakte Kontrolle, oder mit einem KI-Agenten in QGIS, wenn Sie das Ergebnis aus einer einzigen Nachricht in normaler Sprache wollen.

Die Tutorials, die ich gelesen habe, erklären jeweils eine dieser vier Methoden isoliert an einem Spielbeispiel, und keines testet, was passiert, wenn man den Workflow ein zweites Mal für eine neue Stadt ausführt. Am 7. November 2026 habe ich eine mehrstufige Aufgabe (bebaute Fläche je Stadtbezirk aus 180.602 OpenStreetMap-Gebäuden in Bielefeld) mit allen vier Methoden in QGIS 3.44.15 durchgeführt und danach alle vier für Münster wiederholt (135.577 Gebäude, 6 Stadtbezirke). Jede Methode bestand auf beiden Städten, auch wenn ein Durchlauf im Graphical Modeler zunächst mit "OK" endete und dabei 1.058 Polygone statt 10 schrieb.

Was ist QGIS-Automatisierung?

QGIS-Automatisierung bedeutet, ein Processing-Werkzeug oder eine Werkzeugkette über Layer laufen zu lassen, ohne sich von Hand durch jeden Dialog zu klicken. Unter jeder Methode liegt das QGIS-Processing-Framework, dieselbe Engine, die auch die Processing Toolbox (Verarbeitungswerkzeuge) antreibt. Da die Werkzeuge identisch sind, egal ob Sie sie aus einer Stapeltabelle, einem Diagramm im Graphical Modeler, einem Python-Skript oder dem Kommandozeilenwerkzeug qgis_process aufrufen, wählen Sie mit der Automatisierungsmethode eigentlich nur, wie Sie diese Werkzeuge verbinden und welche Datei Sie für den nächsten Monat auf der Festplatte behalten wollen.

Die Aufgabe und die Testdaten

Ich habe eine Aufgabe gewählt, die in Stadtplanung und Beratung ständig vorkommt: für jeden Stadtbezirk die Gebäude auf die Bezirksgrenze zuschneiden, die Grundrisse zählen, ihre Fläche in Quadratmetern summieren, die zugeschnittenen Gebäude um 25 m puffern und zu einem einzigen Polygon der bebauten Fläche verschmelzen, und am Ende ein sauberes GeoPackage mit einer Zeile pro Bezirk speichern.

Liegt ein Gebäude über einer Bezirksgrenze, wird es zugeschnitten und in jedem berührten Bezirk einmal gezählt. Beide Städte nutzen OpenStreetMap-Daten aus PBF-Extrakten von BBBike (ODbL, OpenStreetMap-Mitwirkende), für alle Messungen nach EPSG:25832 (ETRS89 / UTM Zone 32N) reprojiziert.

• Stadt 1, Bielefeld: 180.602 Gebäudepolygone in 10 Stadtbezirken (admin_level=9), daraus 115.002 zugeschnittene Gebäudeteile. Zwei OSM-Rohgebäude hatten ungültige Geometrien und wurden einmal mit Fix geometries (Geometrien reparieren) repariert, damit alle vier Methoden mit denselben sauberen Dateien starteten.
• Stadt 2, Münster (die Wiederholung): 135.577 Gebäudepolygone in 6 Stadtbezirken, daraus 116.382 zugeschnittene Teile.

Bevor ich eine der vier Methoden ausführte, schrieb ich eine unabhängige Referenz mit reinen PyQGIS-Geometrieaufrufen (QgsSpatialIndex, geometry.intersection(), unaryUnion() und buffer(25, 5), ohne Processing-Algorithmen) und speicherte ein Prüfskript. Eine Methode bestand nur, wenn sie ein GeoPackage mit einem Polygon-Layer built_up in EPSG:25832 erzeugte, mit exakten Gebäudezahlen je Bezirk, Grundrissfläche innerhalb von 0,5 % der Referenz, bebauten Hektar innerhalb von 1 % und ohne Nachbearbeitung von Hand.

Methode 1: Stapelverarbeitung (Batch Processing)

Jedes Werkzeug in der Processing Toolbox hat unten links im Dialog eine Schaltfläche Run as Batch Process (Als Stapelprozess starten). Sie verwandelt den Dialog in eine Tabelle, in der jede Zeile ein Durchlauf dieses einen Werkzeugs ist.

Für unsere Aufgabe erledigt die Stapelverarbeitung das Clip je Bezirk und das Buffer je Bezirk sauber, weil diese zwei Schritte genau denselben Algorithmus über die 10 Bezirke wiederholen. Den ganzen Workflow in einem Zug schafft sie aber nicht, denn die Stapelverarbeitung führt immer nur ein Werkzeug aus und hinterlässt 10 einzelne Ausgabe-Layer, die Sie danach noch zusammenführen und wieder verknüpfen müssen.

Über die 9 Durchläufe (8 verschiedene Algorithmen) lag die gesamte Werkzeugzeit für Bielefeld bei 62,0 Sekunden, und jede Bezirkszahl stimmte mit der Referenz überein. Für Münster sank die Werkzeugzeit auf 39,8 Sekunden für 6 Bezirke, aber ich musste die Stapeltabellen mit 6 Zeilen neu aufbauen und alle 9 Schritte von Hand wiederholen. Wenn Ihr Workflow eine Kette verschiedener Werkzeuge ist und nicht ein Werkzeug, das über 50 Dateien wiederholt wird, hat die Stapelverarbeitung die falsche Form.

Methode 2: Der Graphical Modeler (Grafische Modellierung)

Mit dem Graphical Modeler (Processing > Graphical Modeler) verbinden Sie eine Kette von Processing-Werkzeugen zu einem einzigen Diagramm und speichern sie als .model3-Datei. Einmal gebaut, erscheint das Modell in Ihrer Processing Toolbox wie jedes eingebaute Werkzeug.

Man könnte meinen, im Modeler sei eine Schleife über die Bezirke nötig, doch das stimmt nicht. Wenn Sie zuerst Intersection zwischen Gebäuden und Bezirken ausführen, erbt jedes Gebäudeteil das Attribut name seines Bezirks, sodass Aggregate und Dissolve, gruppiert nach name, in einem Durchgang eine Zeile pro Bezirk liefern. (Sie könnten auch eine räumliche Verknüpfung nutzen, wenn die Gebäude nicht exakt an der Bezirksgrenze geteilt werden müssen.)

Das Modell lief aus seinem Dialog für Bielefeld in 62,7 Sekunden und bestand jede Prüfung. Noch besser: Genau dieselbe .model3-Datei lief im macOS-Terminal über qgis_process ohne geöffnetes QGIS-Fenster in 44,5 Sekunden.

Der eigentliche Gewinn zeigte sich bei der Wiederholung für Münster. Ich öffnete denselben Modelldialog, wählte muenster_buildings und muenster_districts in den zwei Auswahllisten und klickte auf Run. Es war in 67,2 Sekunden fertig, ohne eine einzige Änderung am Modell.

Methode 3: Ein PyQGIS-Skript in der Python-Konsole

Wenn Sie mit Python vertraut sind, bekommen Sie mit einem Skript in Plugins > Python Console > Show Editor eine echte for-Schleife, die Eingaben als Variablen oben in der Datei und keine Zusammenführungsschritte.

Hier ist das 38-zeilige Skript (built_up_by_district.py), das ich in QGIS 3.44.15 ausgeführt habe, mit gekürzten Dateipfaden:

# Built-up area by district. Run in the QGIS Python console (Plugins > Python Console > Show Editor > Run).
# Change the first five lines for a new city.
BUILDINGS = "data/bielefeld_buildings.gpkg"
DISTRICTS = "data/bielefeld_districts.gpkg"
NAME_FIELD = "name"
BUFFER_M = 25
OUT = "out/script/built_up_script.gpkg"

import processing
from qgis.core import (QgsVectorLayer, QgsCoordinateReferenceSystem, QgsFeature, QgsField, QgsFields, QgsGeometry)
from qgis.PyQt.QtCore import QVariant

crs = QgsCoordinateReferenceSystem("EPSG:25832")   # metric, Germany
def run(alg, **p):
    return processing.run(alg, p)["OUTPUT"]

buildings = run("native:reprojectlayer", INPUT=BUILDINGS, TARGET_CRS=crs, OUTPUT="memory:")
districts = run("native:reprojectlayer", INPUT=DISTRICTS, TARGET_CRS=crs, OUTPUT="memory:")

result = QgsVectorLayer("MultiPolygon?crs=EPSG:25832", "built_up", "memory")
result.dataProvider().addAttributes([QgsField("district", QVariant.String), QgsField("building_count", QVariant.Int),
                                     QgsField("building_area_m2", QVariant.Double), QgsField("built_up_ha", QVariant.Double)])
result.updateFields()

for d in districts.getFeatures():
    one = run("native:extractbyexpression", INPUT=districts, EXPRESSION=f"$id = {d.id()}", OUTPUT="memory:")
    clipped = run("native:clip", INPUT=buildings, OVERLAY=one, OUTPUT="memory:")
    area = sum(f.geometry().area() for f in clipped.getFeatures())
    built_up = run("native:buffer", INPUT=clipped, DISTANCE=BUFFER_M, SEGMENTS=5, DISSOLVE=True, OUTPUT="memory:")
    geom = next(built_up.getFeatures()).geometry()
    f = QgsFeature(result.fields())
    f.setGeometry(geom)
    f.setAttributes([d[NAME_FIELD], clipped.featureCount(), area, geom.area() / 10000])
    result.dataProvider().addFeature(f)
    print(d[NAME_FIELD], clipped.featureCount(), round(area), round(geom.area() / 10000, 1))

processing.run("native:savefeatures", {"INPUT": result, "OUTPUT": OUT, "LAYER_NAME": "built_up"})
print("saved", OUT)

Das Skript hält jeden Zwischen-Layer im Speicher und läuft in einer Schleife über die Bezirke, und es war mit Abstand die schnellste Methode (warum, haben wir nicht untersucht). Es war für Bielefeld in 8,1 Sekunden fertig und stimmte in jedem Bezirk bis auf 0.00% mit der unabhängigen Referenz überein.

Für die Wiederholung in Münster änderte ich drei Zeilen oben (BUILDINGS, DISTRICTS und OUT) und klickte auf die grüne Run-Script-Schaltfläche. Es war in 7,4 Sekunden fertig. Wie processing.run im Detail funktioniert, lesen Sie in unserem PyQGIS-Leitfaden.

Die vier Methoden im Vergleich auf beiden Städten

Das haben wir am 7. November 2026 für alle vier Methoden gemessen:

Jede Methode traf die Gebäudezahlen und Grundrissflächen (building_area_m2) der Referenz auf 0.00%. Die Abweichung von +0.08% bei built_up_ha für Stapelverarbeitung und Graphical Modeler entsteht, weil $area in Refactor fields auf dem Projektellipsoid misst, während Skript und Referenz die planare geometry().area() in EPSG:25832 verwendeten.

Was unterwegs schiefging (einschließlich einer stillen falschen Antwort)

Tutorials zeigen selten die Durchläufe, die scheitern, deshalb habe ich jeden Fehler des Tages protokolliert. Der unheimlichste Fehler war kein Absturz und keine rote Fehlermeldung, sondern ein Durchlauf im Graphical Modeler, der Erfolg meldete und das falsche Ergebnis lieferte.

Als ich das Modell zum ersten Mal ohne Oberfläche ausführte, bevor ich die Felder im Knoten Intersection beschränkt hatte, stand im Protokoll:

Model processed OK. Executed 8 algorithm(s) total in 84.548 s.

Kein Fehler, keine Warnung. Als ich das Ausgabe-GeoPackage prüfte, hatte built_up 1.058 Polygone statt 10.

Der Grund: OpenStreetMap-Gebäude haben eine eigene Spalte name (der Name eines Ladens, einer Schule oder einer Kirche), und der Bezirks-Layer hat ebenfalls eine Spalte name. Als Intersection alle Felder beider Layer kombinierte, blieb name der Gebäude name, und name des Bezirks wurde still in name_2 umbenannt. Weiter hinten gruppierten Aggregate und Dissolve nach name, also nach Gebäudenamen statt nach Bezirken! Die Beschränkung von Input fields to keep in Intersection auf osm_id verhinderte die Kollision und brachte die Ausgabe zurück auf die 10 Bezirke.

Drei weitere Dinge gingen schief, die Sie kennen sollten, bevor Sie Ihre eigenen Daten automatisieren:

• Ungültige OSM-Geometrien stoppen Processing standardmäßig. Zwei der 180.602 Gebäude in Bielefeld hatten sich selbst schneidende Ringe. Mit der Standardeinstellung von QGIS bricht Clip sofort ab mit Feature (18818404) from 'b' has invalid geometry. Führen Sie Fix geometries als ersten Schritt aus, wenn Ihre Eingabe aus rohen OpenStreetMap-Daten stammt.
• savefeatures in PyQGIS mag keine GDAL-Verbindungszeichenfolgen. Bei meinem ersten Skriptdurchlauf (10,0 s) löste die Übergabe von ogr:dbname='...' table="built_up" an native:savefeatures den Fehler OGR driver for '' not found aus. Übergeben Sie in OUTPUT den einfachen .gpkg-Pfad und setzen Sie LAYER_NAME: "built_up" als eigenen Parameter.
• Das Laden vieler Zwischen-Layer brachte unsere Sitzung zum Absturz. QGIS stürzte dreimal ab (SIGSEGV), während Processing-Ausgaben mit aktiviertem Load layers on completion in den Layerbaum geladen wurden. Ohne den Haken bei den Zwischen-Stapelzeilen hörten die Abstürze auf.

Methode 4: Einen KI-Agenten in QGIS fragen

Wir entwickeln AI Agent, dieser Abschnitt behandelt also unser eigenes Plugin. Es dockt ein Chat-Panel in QGIS an, liest die Layer und Felder, die schon in Ihrem Projekt sind, ruft selbst QGIS-Processing-Werkzeuge und PyQGIS auf und prüft das Ergebnis, bevor es antwortet.

Für eine einmalige Aufgabe oder ein Projekt mit zwei Städten ist es oft mehr Aufwand, als die Aufgabe verdient, ein Modell mit 8 Knoten zu bauen oder ein 38-zeiliges Skript zu debuggen. Ich öffnete ein Projekt mit den Bielefelder Layern buildings und districts, stellte das Panel auf Medium Effort und Balanced Permissions und schickte eine Nachricht:

The project has two layers: "buildings" (OSM buildings of Bielefeld, Germany) and "districts" (its 10 city districts, the district name is in the field "name"). For each district: clip the buildings to the district, count the buildings, sum their footprint area in square meters, and build a 25 m buffer around the clipped buildings, dissolved into one built-up polygon, with its area in hectares. Measure in a metric CRS (EPSG:25832). Write one GeoPackage at [output folder]/built_up_agent.gpkg with a single polygon layer named built_up, one feature per district, fields district, building_count, building_area_m2, built_up_ha, in EPSG:25832. Then show me the result table.

(Ausgabepfade in beiden Prompts gekürzt. Hinweis zur Transparenz: Beim allerersten Versuch stürzte QGIS 9 Sekunden nach dem Klick auf Senden mit einem Segfault in einem Qt-Slot ab, bevor eine Antwort kam. Ich öffnete das Projekt erneut, schickte genau denselben Prompt einmal und danach nicht noch einmal.)

In 110 Sekunden führte der Agent 27 Werkzeugaufrufe aus (12 run_processing, 7 get_algorithm_help, 4 execute_code, 2 get_layer_info, 1 export_layer, 1 get_features), fing einen internen Processing-Fehler selbst ab, ohne eine Berechtigungskarte zu zeigen, schrieb das GeoPackage und gab die Tabelle mit den 10 Bezirken im Chat aus. Ungefragt merkte er in seiner Antwort außerdem an: "The 25 m buffers can extend across district boundaries and overlap."

Dann zog ich muenster_buildings und muenster_districts ins Projekt und tippte im selben Chat eine Folgenachricht mit 46 Wörtern:

Now do the same for Münster. I added two layers: "muenster_buildings" and "muenster_districts" (6 districts, the name is in the field "name"). Same fields and same 25 m buffer, in a new GeoPackage at [output folder]/built_up_agent_muenster.gpkg with the layer named built_up. Then show me the result table.

Mit dem ersten Durchlauf im selben Chat war der Agent für Münster in 60 Sekunden fertig, mit 15 Werkzeugaufrufen (11 run_processing, 1 export_layer, 1 get_features, 1 zoom_to_layer, 1 execute_code) und ohne einen einzigen Fehler.

Jede Gebäudezahl und jede Grundrissfläche stimmte auf beiden Städten bis auf 0.00% mit der Referenz überein.

Wo liegen die Grenzen? Erstens lagen die Werte von built_up_ha beim Agenten 0.07% bis 0.21% über der planaren Referenz (zum Beispiel kam Brackwede auf 1,390.51 ha gegenüber 1,388.31 ha in der Referenz; welcher interne Schritt diesen kleinen Unterschied verursacht hat, haben wir nicht gemessen). Zweitens behielt das exportierte GeoPackage eine zusätzliche Spalte _export_fid. Drittens, und für die Automatisierung am wichtigsten: Der Agent plant seine Schritte bei jeder Nachricht neu (27 Werkzeugaufrufe für Bielefeld, 15 für Münster) und läuft in einer offenen QGIS-Sitzung, er hinterlässt also keine .model3- oder .py-Datei, die Sie mit cron unbeaufsichtigt einplanen können.

Welche Methode zur QGIS-Automatisierung sollten Sie wählen?

Statt ein Werkzeug zum Sieger zu erklären, wählen Sie die Methode danach, wie oft Sie die Aufgabe wiederholen:

• Sie führen genau ein Werkzeug über 10 bis 100 Dateien aus: Nutzen Sie die Stapelverarbeitung. Sie steckt in jedem Processing-Dialog, kostet nichts und braucht keinen Code. Hören Sie damit auf, sobald Ihr Workflow drei oder vier verschiedene Werkzeuge verkettet.
• Sie oder Ihr Team führen jeden Monat oder per Server-Zeitplan eine mehrstufige Kette aus: Bauen Sie sie im Graphical Modeler. Sie erhalten eine einzige .model3-Datei, die Sie mit Kollegen teilen können, die kein Python schreiben, und die Sie über qgis_process ohne Oberfläche aus einem Shell-Skript oder einer geplanten Aufgabe ausführen können.
• Sie brauchen eigene Schleifen, exakte planare Kontrolle oder die schnellste Ausführung: Schreiben Sie ein PyQGIS-Skript. Unser 38-zeiliges Skript lief auf beiden Städten 8- bis 9-mal schneller als der Modeler.
• Sie haben heute eine komplexe Aufgabe, die Sie einmal, zweimal oder in wenigen Projektvarianten ausführen: Nutzen Sie einen KI-Agenten in QGIS wie AI Agent (oder lesen Sie unsere breitere Übersicht im QGIS-AI-Hub). Sie müssen keine exakten Werkzeugnamen suchen und wiederholen die Aufgabe für eine zweite Stadt mit einem Satz. Der Free-Plan bietet 5 Aufgaben im Monat mit Low Effort; diese Tests liefen mit Medium, das im Pro-Plan enthalten ist (49 EUR / Monat zzgl. MwSt., 300 Aufgaben).

So haben wir gemessen. Alle Tests liefen am 7. November 2026 auf einem Mac mit Apple Silicon (macOS 27.0.1, arm64) in einer isolierten Sitzung von QGIS 3.44.15-Solothurn (Python 3.12.11) mit AI Agent 1.9.4 (Medium Effort, Balanced Mode). Die Last der Maschine schwankte über den Tag, vergleichen Sie die Zeiten also als Größenordnungen, nicht als CPU-Benchmarks. Wir haben die reale Ausführungszeit der Maschine und die Zahl der Schritte gemessen, nicht die Minuten, die ein GIS-Analyst braucht, um ein Modell zusammenzuklicken oder ein Skript von Grund auf zu schreiben. Alle Eingaben, die .model3-Datei, die .py-Skripte, das Prüfskript für die Referenz und die rohen JSON-Protokolle liegen in unserem Experimentarchiv.

Häufig gestellte Fragen

Wie automatisiere ich einen wiederkehrenden Workflow in QGIS?

Je nachdem, wie oft sich die Aufgabe wiederholt, haben Sie vier Hauptoptionen. Für ein einzelnes Werkzeug über viele Dateien klicken Sie im Dialog des Werkzeugs auf Run as Batch Process. Für eine mehrstufige Kette, die Sie regelmäßig erneut ausführen, verbinden Sie die Werkzeuge in Processing > Graphical Modeler und speichern eine .model3-Datei. Für Schleifen und die schnellste Ausführung schreiben Sie ein Python-Skript mit processing.run() in der QGIS-Python-Konsole. Für einmalige oder seltene Analysen, bei denen Sie weder Knoten verbinden noch Code schreiben wollen, beschreiben Sie den Workflow in einfachen Worten in einem Agenten-Plugin wie AI Agent.

Sollte ich den QGIS Graphical Modeler oder Python (PyQGIS) verwenden?

Nutzen Sie den Graphical Modeler, wenn Ihr Workflow eine gerade Kette von Processing-Algorithmen ist und Sie eine visuelle .model3-Datei wollen, die auch Nicht-Programmierer in Ihrem Team öffnen können oder die Sie mit qgis_process von der Kommandozeile ausführen. Nutzen Sie PyQGIS, wenn Sie über Objekte iterieren, Zwischen-Layer im Speicher halten (das Skript lief in unserem Bielefeld-Test in 8,1 s gegenüber 62,7 s für das Modell), Fehler im Code behandeln oder Ausgabeschemata explizit steuern müssen.

Kann ich ein QGIS-Modell aus dem Graphical Modeler als Python-Skript exportieren?

Ja. Der Graphical Modeler kann ein Modell als Python-Processing-Skript exportieren (Export as Script Algorithm), das Sie dann bearbeiten können, um Schleifen, Variablen oder eigene Logik hinzuzufügen. Den Export haben wir in diesem Vergleich nicht getestet.

Kann QGIS automatisierte Workflows nach Zeitplan ausführen, ohne die Anwendung zu öffnen?

Ja. QGIS bringt ein Kommandozeilenwerkzeug namens qgis_process mit. Sie können ihm jeden eingebauten Algorithmus oder jede gespeicherte .model3-Datei übergeben (zum Beispiel qgis_process run model3 --BUILDINGS=... --DISTRICTS=... --built_up=...), aus einem Bash-Skript, der Windows-Aufgabenplanung oder einem cron-Job, ohne die grafische Oberfläche von QGIS zu starten. In unserem Bielefeld-Test lief das Modell über qgis_process ohne Oberfläche in 44,5 Sekunden.

AI Agent kostenlos testen

WeiterlesenWas ist PyQGIS? QGIS mit Python automatisieren