Automatizzare QGIS: un'attività, 4 metodi, cronometrati su 2 città
Pubblicato il
Puoi automatizzare un flusso di lavoro ripetitivo in QGIS in quattro modi: l'elaborazione in batch (Batch Processing) per un solo strumento su molti file, il Graphical Modeler (modellatore grafico) per una catena di strumenti da rieseguire, uno script PyQGIS per i cicli e il controllo preciso, oppure un agente IA dentro QGIS quando vuoi il risultato da un solo messaggio in linguaggio semplice.
I tutorial che ho letto insegnano uno di questi quattro metodi da solo, su un esempio giocattolo, e nessuno verifica cosa succede quando esegui il flusso una seconda volta su una nuova città. Il 7 novembre 2026 ho preso un'attività in più passaggi (l'area edificata per quartiere a partire da 180.602 edifici OpenStreetMap a Bielefeld, in Germania), l'ho eseguita con tutti e quattro i metodi in QGIS 3.44.15 e poi li ho rieseguiti tutti e quattro su Münster (135.577 edifici, 6 quartieri). Ogni metodo ha superato la verifica su entrambe le città, anche se un'esecuzione del Graphical Modeler all'inizio è terminata con "OK" scrivendo 1.058 poligoni invece di 10.
8.1s
Script PyQGIS su Bielefeld (7,4 s su Münster)
62.7s
Graphical Modeler in QGIS (44,5 s headless)
60s
Test di AI Agent ripetuto su Münster da 1 frase
1,058righe
Scritte invece di 10 per un bug silenzioso del modello
Che cos'è l'automazione in QGIS?
Automatizzare QGIS significa eseguire uno strumento di elaborazione, o una catena di strumenti, su più layer senza passare a mano da una finestra all'altra. Sotto ogni metodo c'è il framework Processing di QGIS, lo stesso motore che alimenta il Processing Toolbox. Dato che gli strumenti sono identici sia che li chiami da una tabella batch, da un diagramma del Graphical Modeler, da uno script Python o dallo strumento a riga di comando qgis_process, scegliere un metodo di automazione significa in realtà scegliere come collegare quegli strumenti tra loro e quale file vuoi ritrovare sul disco il mese prossimo.
L'attività e i dati del test
Ho scelto un lavoro che capita di continuo nella pianificazione urbana e nella consulenza: per ogni quartiere della città, ritagliare gli edifici sul confine del quartiere, contare le impronte, sommarne l'area in metri quadrati, applicare un buffer di 25 m agli edifici ritagliati e dissolverli in un unico poligono edificato, poi salvare un solo GeoPackage pulito con una riga per quartiere.
Se un edificio attraversa il confine tra due quartieri, viene ritagliato e contato una volta in ogni quartiere che tocca. Entrambe le città usano dati OpenStreetMap da estratti PBF di BBBike (ODbL, contributori di OpenStreetMap), riproiettati in EPSG:25832 (ETRS89 / UTM zona 32N) per tutte le misure.
- Città 1, Bielefeld: 180.602 poligoni di edifici in 10 quartieri (
admin_level=9), che producono 115.002 pezzi di edifici ritagliati. Due edifici OSM grezzi avevano geometrie non valide e sono stati riparati una volta con Fix geometries, così tutti e quattro i metodi partivano dagli stessi file puliti. - Città 2, Münster (la seconda esecuzione): 135.577 poligoni di edifici in 6 quartieri, che producono 116.382 pezzi ritagliati.
Prima di provare i quattro metodi, ho scritto un riferimento indipendente con semplici chiamate di geometria PyQGIS (QgsSpatialIndex, geometry.intersection(), unaryUnion() e buffer(25, 5), senza chiamare algoritmi di Processing) e ho salvato uno script di controllo. Un metodo superava la verifica solo se produceva un GeoPackage con un layer poligonale built_up in EPSG:25832, il conteggio esatto degli edifici per quartiere, l'area delle impronte entro lo 0,5% del riferimento, gli ettari edificati entro l'1% e nessuna modifica a mano dopo.
Metodo 1: l'elaborazione in batch
Ogni strumento del Processing Toolbox ha un pulsante Run as Batch Process (Esegui come processo batch) nell'angolo in basso a sinistra della sua finestra. Trasforma la finestra in un foglio di calcolo in cui ogni riga è un'esecuzione di quel singolo strumento.
Per la nostra attività, l'elaborazione in batch gestisce bene il Clip e il Buffer per quartiere, perché quei due passaggi ripetono esattamente lo stesso algoritmo sui 10 quartieri. Non può però fare tutto il flusso in una volta, perché il Batch Processing esegue un solo strumento alla volta e ti lascia 10 layer di output separati che devi ancora unire e ricollegare.
Riproietta e dividi gli input
Esegui Reproject layer (Vector general) sugli edifici verso EPSG:25832. Poi esegui Split vector layer (Vector general) sul layer dei quartieri usando il campo name, che scrive un GeoPackage per quartiere in una cartella.
Esegui Clip in batch su tutti i quartieri
Apri Clip (Vector overlay), clicca Run as Batch Process e aggiungi una riga per ogni file di quartiere. Imposta gli edifici riproiettati come Input layer, usa Autofill per compilare i layer di sovrapposizione dei quartieri e i nomi delle tabelle di output (clip_<district>), e togli la spunta a Load layers on completion. Su Bielefeld, tutte le 10 righe sono terminate in 13,7 s (da 1,0 a 4,2 s per quartiere).
Esegui Buffer in batch con Dissolve attivo
Apri Buffer (Vector geometry) in modalità batch: una riga per layer ritagliato, Distance 25, Segments 5 e Dissolve result spuntato. I 10 buffer di Bielefeld sono stati eseguiti in 27,7 s.
Unisci, aggrega e ricollega la tabella
Esegui Merge vector layers due volte (una sui 10 layer di clip, una sui 10 layer di buffer). Esegui Aggregate (Vector geometry) sulle clip unite, raggruppate per il campo layer, per ottenere building_count (count($id)) e building_area_m2 (sum(area($geometry))). Esegui Refactor fields (Vector table) sui buffer uniti per calcolare built_up_ha con l'espressione del calcolatore di campi $area / 10000, poi Join attributes by field value (Vector general) su district per produrre l'unico layer di output.

Sulle 9 esecuzioni (8 algoritmi diversi), il tempo totale degli strumenti su Bielefeld è stato di 62,0 secondi, e ogni conteggio per quartiere corrispondeva al riferimento. Su Münster il tempo degli strumenti è sceso a 39,8 secondi per 6 quartieri, ma ho dovuto ricostruire le tabelle batch da 6 righe e rieseguire a mano tutti i 9 passaggi. Quando il tuo flusso è una catena di strumenti diversi e non uno strumento ripetuto su 50 file, il Batch Processing non è la forma giusta.
Metodo 2: il Graphical Modeler
Il Graphical Modeler (Processing > Graphical Modeler) ti permette di collegare una catena di strumenti di Processing in un unico diagramma e salvarlo come file .model3. Una volta creato, il modello compare nel Processing Toolbox come qualsiasi strumento nativo.
Potresti pensare di aver bisogno di un ciclo sui quartieri dentro il Modeler, ma non serve. Eseguendo prima Intersection tra edifici e quartieri, ogni pezzo di edificio eredita l'attributo name del suo quartiere, quindi Aggregate e Dissolve raggruppati per name producono una riga per quartiere in un solo passaggio. (Potresti anche usare un join spaziale se non ti serve che gli edifici siano tagliati esattamente sulla linea del quartiere.)
Aggiungi i tre input del modello
In un nuovo modello, aggiungi due input Vector Layer (Polygons) chiamati Buildings e Districts, e un input Number chiamato Buffer distance (m) con valore predefinito 25.
Riproietta entrambi gli input e intersecali
Aggiungi due nodi Reproject layer con destinazione EPSG:25832. Collegali entrambi a un nodo Intersection (Buildings come Input, Districts come Overlay). In Input fields to keep di Intersection, limita i campi degli edifici al solo osm_id, e in Overlay fields to keep tieni name.
Dividi in Aggregate per i conteggi e Dissolve + Buffer per la geometria
Da Intersection, collega un ramo ad Aggregate raggruppato per name per calcolare count($id) e sum(area($geometry)). Collega un secondo ramo da Intersection a Dissolve (campo name) seguito da Buffer (collegato al tuo input Buffer distance (m), 5 segmenti).
Unisci i rami e formatta la tabella di output
Aggiungi Join attributes by field value per collegare la tabella di Aggregate ai poligoni con buffer su name, poi Refactor fields per rinominare name in district e calcolare built_up_ha come $area / 10000. Imposta l'output come built_up e salva il modello come built_up_by_district.model3.

Eseguire il modello dalla sua finestra su Bielefeld ha richiesto 62,7 secondi e ha superato ogni controllo. Ancora meglio, lo stesso identico file .model3 è stato eseguito dal terminale di macOS, senza aprire una finestra di QGIS, tramite qgis_process in 44,5 secondi.
Il vero vantaggio si è visto nella seconda esecuzione su Münster. Ho aperto la stessa finestra del modello, ho selezionato muenster_buildings e muenster_districts nei due menu a tendina e ho cliccato Run. È terminato in 67,2 secondi senza alcuna modifica al modello.

Metodo 3: uno script PyQGIS nella Python Console
Se sei a tuo agio con Python, uno script dentro Plugins > Python Console > Show Editor ti dà un vero ciclo for, gli input come variabili in cima al file e nessun passaggio di unione.
Ecco lo script di 38 righe (built_up_by_district.py) che ho eseguito in QGIS 3.44.15, con i percorsi dei file abbreviati:
# 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)
Lo script tiene in memoria ogni layer intermedio e cicla sui quartieri, ed è stato di gran lunga il metodo più veloce (non abbiamo profilato il motivo). Ha terminato Bielefeld in 8,1 secondi e ha corrisposto al riferimento indipendente con uno scarto dello 0.00% su ogni quartiere.

Per rieseguirlo su Münster, ho cambiato tre righe in cima (BUILDINGS, DISTRICTS e OUT) e ho cliccato il pulsante verde Run Script. È terminato in 7,4 secondi. Se vuoi capire nel dettaglio come funziona processing.run, leggi la nostra guida a PyQGIS.
Come si sono confrontati i quattro metodi sulle due città
Ecco cosa abbiamo misurato con tutti e quattro i metodi il 7 novembre 2026:
| Batch Processing | Graphical Modeler | Script PyQGIS | AI Agent (Medium, Balanced) | |
|---|---|---|---|---|
| Impostazione / struttura | 9 esecuzioni con 8 algoritmi (2 tabelle batch da 10 righe) | 3 input + 8 nodi di algoritmi + 1 output | 38 righe di Python, 5 algoritmi | 1 messaggio in linguaggio semplice (27 chiamate di strumenti dell'agente) |
| Tempo su Bielefeld (10 quartieri) | 62,0 s di tempo strumenti (avviati uno per uno) | 62,7 s nella finestra (44,5 s via qgis_process) | 8,1 s (dopo aver corretto 1 chiamata di salvataggio fallita) | 110 s da Invia alla tabella di risposta |
| Seconda esecuzione su Münster (6 quartieri) | 39,8 s di tempo strumenti (ricostruire le righe batch e tutte le 9 esecuzioni) | 67,2 s (scegliere 2 nuovi layer, cliccare Run) | 7,4 s (cambiare 3 righe di percorso, cliccare Run) | 60 s (1 messaggio di seguito di 46 parole, 15 chiamate di strumenti) |
Scarto massimo dal riferimento (built_up_ha) | +0,08% | +0,08% | 0,00% | +0,21% |
| Cosa resta dopo | ~20 layer intermedi | Un file .model3 (gira nell'interfaccia o headless) | Un file di script .py | La cronologia della chat e il testo del prompt |
Ogni metodo ha corrisposto al riferimento per il conteggio degli edifici e l'area delle impronte (building_area_m2) con uno scarto dello 0.00%. La differenza di +0.08% su built_up_ha per il Batch Processing e il Graphical Modeler viene da $area in Refactor fields, che misura sull'ellissoide del progetto, mentre lo script e il riferimento usavano l'area planare geometry().area() in EPSG:25832.
Cosa si è rotto lungo la strada (compresa una risposta sbagliata silenziosa)
I tutorial mostrano di rado le esecuzioni che falliscono, quindi ho annotato ogni errore della giornata. Il guasto più preoccupante non è stato un crash né un banner di errore rosso: è stata un'esecuzione del Graphical Modeler che ha segnalato successo e ha dato l'output sbagliato.
Quando ho eseguito il modello headless per la prima volta, prima di limitare i campi sul nodo Intersection, il log ha stampato:
Model processed OK. Executed 8 algorithm(s) total in 84.548 s.
Nessun errore, nessun avviso. Quando ho controllato il GeoPackage di output, built_up aveva 1.058 poligoni invece di 10.
Ecco perché: gli edifici di OpenStreetMap hanno una propria colonna name (il nome di un negozio, di una scuola o di una chiesa), e anche il layer dei quartieri ha una colonna name. Quando Intersection ha combinato tutti i campi dei due layer, il name degli edifici è rimasto name e il name del quartiere è stato rinominato in silenzio in name_2. A valle, Aggregate e Dissolve hanno raggruppato per name, quindi per nome dell'edificio invece che per quartiere! Limitare Input fields to keep di Intersection a osm_id ha evitato la collisione e ha riportato l'output ai 10 quartieri.
Altre tre cose si sono rotte e vale la pena saperle prima di automatizzare i tuoi dati:
- Le geometrie OSM non valide fermano Processing per impostazione predefinita. Due dei 180.602 edifici di Bielefeld avevano anelli autointersecanti. Con l'impostazione predefinita di QGIS, Clip si ferma subito con
Feature (18818404) from 'b' has invalid geometry. Esegui Fix geometries come primo passaggio ogni volta che il tuo input viene da OpenStreetMap grezzo. savefeaturesin PyQGIS non gradisce le stringhe di connessione GDAL. Alla mia prima esecuzione dello script (10,0 s), passareogr:dbname='...' table="built_up"anative:savefeaturesha sollevatoOGR driver for '' not found. Passa il semplice percorso.gpkginOUTPUTe impostaLAYER_NAME: "built_up"come parametro separato.- Caricare molti layer intermedi ha fatto crashare la nostra sessione. QGIS è andato in crash (
SIGSEGV) tre volte mentre gli output di Processing si caricavano nel pannello dei layer con Load layers on completion spuntato. Togliere la spunta per le righe batch intermedie ha fermato i crash.
Metodo 4: chiedere a un agente IA dentro QGIS
Sviluppiamo AI Agent, quindi questa sezione parla del nostro plugin. Aggiunge un pannello di chat dentro QGIS, esamina i layer e i campi già presenti nel progetto, chiama da solo gli strumenti di Processing di QGIS e PyQGIS, e controlla l'output prima di rispondere.
Per un lavoro occasionale o un progetto su due città, costruire un modello grafico a 8 nodi o fare il debug di uno script di 38 righe è spesso più lavoro di preparazione di quanto l'attività meriti. Ho aperto un progetto con i layer buildings e districts di Bielefeld, ho impostato il pannello su effort Medium e permessi Balanced, e ho inviato un solo messaggio:
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.
(Percorsi di output abbreviati in entrambi i prompt. Nota di trasparenza: al primissimo tentativo, QGIS è andato in crash 9 secondi dopo che ho cliccato Invia, con un segfault di uno slot Qt, prima che arrivasse qualsiasi risposta. Ho riaperto il progetto, ho inviato una volta lo stesso identico prompt e non l'ho più reinviato.)
In 110 secondi, l'agente ha fatto 27 chiamate di strumenti (12 run_processing, 7 get_algorithm_help, 4 execute_code, 2 get_layer_info, 1 export_layer, 1 get_features), si è ripreso da solo da un errore interno di Processing senza mostrare una scheda di permesso, ha scritto il GeoPackage e ha stampato la tabella dei 10 quartieri nella chat. Senza che glielo chiedessi, ha anche notato nella risposta: "I buffer di 25 m possono estendersi oltre i confini dei quartieri e sovrapporsi."

Poi ho trascinato muenster_buildings e muenster_districts nel progetto e ho scritto un messaggio di seguito di 46 parole nella stessa chat:
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.
Con il primo test nella stessa chat, l'agente ha terminato Münster in 60 secondi con 15 chiamate di strumenti (11 run_processing, 1 export_layer, 1 get_features, 1 zoom_to_layer, 1 execute_code) e zero errori.

Ogni conteggio degli edifici e ogni area delle impronte ha corrisposto al riferimento con uno scarto dello 0.00% su entrambe le città.
Dove sono i limiti? Primo, i valori built_up_ha dell'agente erano dallo 0.07% allo 0.21% sopra il riferimento planare (per esempio, Brackwede è risultato 1,390.51 ha contro 1,388.31 ha nel riferimento; non abbiamo misurato quale passaggio interno abbia causato questa piccola differenza). Secondo, il GeoPackage esportato ha conservato una colonna _export_fid in più. Terzo, e più importante per l'automazione: l'agente pianifica i passaggi da zero a ogni messaggio (27 chiamate di strumenti su Bielefeld, 15 su Münster) e lavora dentro una sessione QGIS aperta, quindi non ti lascia un file .model3 o .py da programmare senza supervisione con cron.

Quale metodo di automazione QGIS scegliere?
Invece di decretare un vincitore, scegli il metodo in base a quanto spesso ripeterai il lavoro:
- Esegui lo stesso identico strumento su 10-100 file: usa il Batch Processing. È integrato in ogni finestra di Processing, non costa nulla e non richiede codice. Smetti di usarlo appena il tuo flusso concatena tre o quattro strumenti diversi.
- Tu o il tuo team eseguirete una catena in più passaggi ogni mese, o su una pianificazione server: costruiscila nel Graphical Modeler. Ottieni un unico file
.model3da condividere con colleghi che non scrivono Python, e puoi eseguirlo headless da uno script di shell o da un'attività pianificata tramiteqgis_process. - Ti servono cicli personalizzati, un controllo planare preciso o la massima velocità di esecuzione: scrivi uno script PyQGIS. Il nostro script di 38 righe è stato da 8 a 9 volte più veloce del Modeler su entrambe le città.
- Hai un'attività complessa da eseguire una volta, due volte o su qualche variante di progetto oggi: usa un agente IA dentro QGIS come AI Agent (oppure leggi la nostra panoramica più ampia sull'hub QGIS AI). Non devi cercare i nomi esatti degli strumenti e rifai il lavoro su una seconda città con una frase. Il piano Free offre 5 attività al mese con effort Low; questi test sono stati eseguiti con effort Medium, incluso nel piano Pro (49 EUR / mese IVA esclusa, 300 attività).
Come abbiamo misurato. Tutti i test sono stati eseguiti il 7 novembre 2026 su un Mac Apple Silicon (macOS 27.0.1, arm64) in una sessione isolata di QGIS 3.44.15-Solothurn (Python 3.12.11) con AI Agent 1.9.4 (effort Medium, modalità Balanced). Il carico della macchina è variato durante la giornata, quindi confronta i tempi come ordini di grandezza, non come benchmark della CPU. Abbiamo misurato il tempo di esecuzione reale della macchina e il numero di passaggi, non i minuti che un analista GIS impiega per montare un modello o scrivere uno script da zero. Tutti gli input, il file .model3, gli script .py, lo script di controllo del riferimento e i log JSON grezzi sono conservati nel nostro archivio dell'esperimento.
Domande frequenti
Come si automatizza un flusso di lavoro ripetitivo in QGIS?
Hai quattro opzioni principali, a seconda di quanto spesso si ripete il lavoro. Per un solo strumento su molti file, clicca Run as Batch Process nella finestra dello strumento. Per una catena in più passaggi da rieseguire regolarmente, collega gli strumenti in Processing > Graphical Modeler e salva un file .model3. Per i cicli e le prestazioni migliori, scrivi uno script Python con processing.run() nella Python Console di QGIS. Per analisi occasionali, quando non vuoi collegare nodi né scrivere codice, descrivi il flusso a parole semplici in un plugin ad agente come AI Agent.
Meglio il Graphical Modeler di QGIS o Python (PyQGIS)?
Usa il Graphical Modeler quando il tuo flusso è una catena lineare di algoritmi di Processing e vuoi un file visivo .model3 che i colleghi non programmatori possano aprire, o che tu possa eseguire da riga di comando con qgis_process. Usa PyQGIS quando devi ciclare sugli elementi, tenere i layer intermedi in memoria (lo script ha impiegato 8,1 s contro 62,7 s del modello nel nostro test su Bielefeld), gestire gli errori nel codice o controllare in modo esplicito lo schema dell'output.
Posso esportare un modello grafico di QGIS in uno script Python?
Sì. Il Graphical Modeler può esportare un modello come script Python di Processing (Export as Script Algorithm), che puoi poi modificare per aggiungere cicli, variabili o logica personalizzata. In questo confronto non abbiamo testato l'esportazione.
QGIS può eseguire flussi automatizzati in modo pianificato senza aprire l'applicazione?
Sì. QGIS include un'utilità a riga di comando chiamata qgis_process. Puoi passarle qualsiasi algoritmo nativo o qualsiasi file .model3 salvato (per esempio, qgis_process run model3 --BUILDINGS=... --DISTRICTS=... --built_up=...) da uno script bash, dall'Utilità di pianificazione di Windows o da un job cron, senza avviare l'interfaccia grafica di QGIS. Nel nostro test su Bielefeld, il modello è stato eseguito headless tramite qgis_process in 44,5 secondi.
Continua a leggereCos'è PyQGIS: automatizza QGIS con o senza codice
Fallo in QGIS semplicemente chiedendolo
AI Agent esegue l'attività che descrivi, direttamente nel tuo progetto QGIS. Gratis, senza carta.
in quattro modi: l'elaborazione in batch (Batch Processing) per un solo strumento su molti file, il Graphical Modeler (modellatore grafico) per una catena di strumenti da rieseguire, uno script 

