Ottimizzare progetti QGIS su LAN: un procedimento sperimentale per velocizzare la consultazione in rete
(Tempo di lettura 9 minuti)
Contenuto in sintesi
- Da dove nasce il problema: un progetto QGIS, con un’elevato contenuto informativo e funzionale, può lavorare in modo fluido sul computer su cui viene sviluppato ma diventa lentissimo quando lo si condivide con i colleghi attraverso la rete aziendale.
- La soluzione: calcolare in anticipo il rendering del progetto a più scale e renderlo disponibile come un unico Cloud Optimized GeoTIFF (COG).
- Come funziona: uno script in Python, da caricare tra gli algoritmi di Processing, produce il rendering del progetto a tre scale e GDAL lo assembla in un raster ottimizzato multiscala, da usare al posto dei layer originali alle scale di consultazione più comuni.
- Risultati dei test: rendering medio da 63,58 s a 1,29 s (circa 49,3× più veloce); traffico di rete durante il rendering da 3.317 MB a 39,6 MB (circa −99%).
- Il limite principale: il file raster è una «fotografia» del progetto. Va bene per consultare la mappa, non per identificare o selezionare oggetti, e va rigenerato quando cambiano dati o stili.
- Codice: prototipo non ancora revisionato da sviluppatori esperti, disponibile su GitHub con licenza CC BY-SA 4.0.
- Contesto: questo contributo descrive la soluzione presentata a Trento nel corso dell’evento FOSS4G-IT & OSMit 2026.
Breve glossario per apprendisti GIS
- COG (Cloud Optimized GeoTIFF): immagine raster che mantiene la stessa estensione .tiff di un GeoTIFF ma risulta organizzata internamente in modo da permettere letture selettive. Viene supportato nativamente da QGIS tramite le librerie GDAL.
- Tile (tassello): porzione minima dell’immagine, di norma 512×512 pixel, che può essere letta singolarmente.
- Overview (panoramica): versione a risoluzione ridotta della stessa immagine, come i livelli di zoom di una mappa online.
- VRT (Virtual Raster): file virtuale che combina più raster in un mosaico virtuale, senza duplicare i dati.
- Sovrascrittura definita dai dati (data-defined override): meccanismo che rende dinamiche le proprietà grafiche dei layer, come dimensione, colore, rotazione, posizione e visibilità in base alla scala, calcolandole dagli attributi del layer o da espressioni.
- PAL (Placement Automatique de Légendes o Placement Algorithm): il motore di etichettatura di QGIS.
- Cache fredda / calda: alla prima lettura (cache fredda o “cold cache”) GDAL deve aprire il raster e leggerne i metadati; nelle successive (cache calda o “hot cache”) parte di queste informazioni sono già in memoria .
Il problema: un progetto locale che fatica sulla LAN
«GISDIS FVG» è un applicativo basato su QGIS, dedicato all’attività istruttoria e cartografica correlata alla programmazione e realizzazione delle opere di difesa del suolo nella Regione Autonoma Friuli Venezia Giulia. Si avvale di codice PyQGIS personalizzato che estende le funzionalità di QGIS e permette di accedere a servizi API remoti, di recuperare in tempo reale foto, relazioni conservate su server SharePoint, dati OpenCUP, e di consultare servizi WMS (PGRA, catasto, ortofoto IRDAT, ISPRA). Comprende oltre 60 layer vettoriali tematizzati, 29 dei quali visibili alla scala di apertura e raster di sfondo (ortofoto, HillShade, rilievo ombreggiato a tinte ipsometriche).
Finché i livelli informativi del progetto sono memorizzati in locale, la fruibilità risulta adeguata e l’interazione gestibile. La criticità si presenta quando viene distribuito su una condivisione di rete NTFS: in tale circostanza il trasferimento dei dati dal server al client risulta limitato dalla larghezza di banda. La causa più probabile è l'elevato volume di dati che transita sulla rete condivisa da tutta la struttura regionale, ciò porta a un aumento della latenza che rende poco reattiva la navigazione cartografica.
Non essendo possibile diminuire il numero di layer né semplificare il progetto, ho cercato di ridurre il carico computazionale necessario per rappresentare la mappa alle scale più usate, spostando una parte dell’elaborazione dalla fase di consultazione a una fase di preparazione.
La strategia adottata: due soluzioni combinate
La soluzione combina due procedimenti distinti:
- Pre-renderizzare il progetto. Invece di far disegnare a ogni zoom i 29 layer, con stili, regole di visibilità ed etichette, QGIS legge un’immagine già pronta ottenuta sovrapponendo i layer visibili all’apertura della mappa con tutti i loro dettagli stilistici, comprese le regole di sovrascrittura definita dai dati.
- Usare il formato COG. L’immagine è organizzata in modo che il software legga solo i tasselli e il livello di risoluzione necessari alla vista corrente, senza caricare tutto il file.
I benchmark, riportati più avanti, confrontano il progetto tradizionale con quello ottimizzato e misurano quindi l’effetto combinato delle due soluzioni parziali, non solo il contributo del formato COG.
Nello schema a sinistra viene rappresentato il PC client che legge dalla rete 29 layer e servizi WMS; in quello a destra il client QGIS che legge pochi tasselli da un solo file COG
COG e GeoTIFF classico: che cosa cambia
Il COG non è un formato nuovo: è un GeoTIFF ma con una disposizione interna ottimizzata. Il tiling divide l’immagine in tasselli; le overview memorizzano versioni a risoluzione ridotta, pronte per le scale più piccole. Nel GeoTIFF classico i pixel sono memorizzati in sequenza, senza una struttura per l’accesso selettivo. Ciò comporta che la lettura dalla rete, dopo uno zoom o uno spostamento, può diventare dispendiosa in termini di elaborazione. Invece, con il formato COG, se il software utilizzato risulta compatibile, vengono letti solo i blocchi e i livelli di risoluzione pertinenti all’area della mappa visualizzata sullo schermo.
Per effettuare una conversione con GDAL, da GeoTIFF a COG, dalla riga di comando (CLI) di OSGeo4W:
gdal_translate in.tif out.tif -of COG -co COMPRESS=LZW
Nella presente soluzione, il raster classico misura 16.682 × 9.013 pixel e pesa circa 131 MB. La versione COG multiscala ha tre livelli a 150 DPI (11.898 × 6.456, 5.952 × 3.228 e 2.976 × 1.614 pixel) e pesa circa 94 MB in totale. I due raster non hanno lo stesso contenuto, quindi il confronto è indicativo, e i valori dipendono da dati, compressione e parametri.
Una piramide pensata per le scale di consultazione
Il prototipo dello script per Processing «Render_Multiscale_Cog_Proc.py» prepara tre scale di riferimento: 1:150.000 (livello base), 1:300.000 (overview 2×) e 1:600.000 (overview 4×). Sotto 1:100.000 il progetto passa alla visualizzazione dei layer QGIS originali. La configurazione predefinita è tarata su territori inferiori a 30.000 km².
Piramide isometrica del COG con tre livelli di risoluzione (1:600.000, 1:300.000, 1:150.000) divisi in tasselli 6x6
Il raster è una fotografia cartografica del progetto a queste scale: consente una consultazione rapida, ma non sostituisce i layer originali quando servono interazione, selezione degli oggetti o consultazione degli attributi.
Per ovviare in parte a questo limite, nel progetto GISDIS FVG viene caricato sopra il COG un layer puntuale con i singoli interventi di difesa del suolo, che può essere interrogato per ciascuna opera censita. Per semplicità espositiva risulta escluso dalla presente trattazione.
A differenza del formato MBTiles, che di norma prevede tasselli in Web Mercator con livelli di zoom prefissati, il COG mantiene il sistema di riferimento proiettato del progetto (in questo caso RDN2008 / TM33) e permette di calcolare le overview in base a risoluzioni corrispondenti alle scale di consultazione. In questo modo, il passaggio tra raster e layer vettoriali originali, che avviene alla scala 1:100.000, risulta più regolare, senza evidenti salti di scala o scatti visivi.
Quando deve mostrare una vista, il client non legge l’intero livello informativo: GDAL individua i tasselli che intersecano l’estensione e la scala correnti e chiede solo i loro byte. Da un server web le richieste sono trattate come HTTP «Byte-Range», mentre se ci si trova su una rete condivisa, come in quella regionale, vengono effettuate letture parziali del file dal server di rete (SMB/NTFS). Lo schema seguente mostra il caso di 4 tasselli su 36, circa l’11% dei tasselli del livello.
Lo script PyQGIS: automatizzare il rendering
Lo script «Render_Multiscale_Cog_Proc.py» si carica tra gli algoritmi di Processing di QGIS.
|
Prima utilizzando l’opzione “Aggiungi Script agli Strumenti” che compare cliccando l’icona Python |
In seguito lanciando l’algoritmo presente in Script ➔ GISDIS FVG |
 |
 |
L’algoritmo visualizza una finestra di dialogo, simile alla tabella sotto riportata, contenente l’estensione presa da un layer di riferimento (o da specificare manualmente) ed altri parametri predefiniti ma modificabili, e produce i materiali intermedi per costruire il COG.
| Parametro | Valore predefinito | Note |
|---|---|---|
| Layer di riferimento per l’estensione | — | La sua estensione diventa l’area di rendering; in alternativa si inserisce un’estensione manuale |
| DPI di rendering | 96 | La risoluzione in metri/pixel è calcolata da scala e DPI, predefinito 96 consigliato 150 |
| Colonne / righe della griglia | 6 / 6 | 6 × 6 = 36 tile per scala |
| Scale incluse | 1:150.000, 1:300.000, 1:600.000 | Livello base e due overview (2× e 4×) |
| Margine scala-overview | 5% | Anticipa il passaggio di GDAL da un’overview all’altra |
| Compressione | DEFLATE, livello 9 | In alternativa ZSTD (decompressione più veloce su LAN) |
| Cartella di output | C:\temp\cog_fvg | Tile PNG, file .bat e .py intermedi |
Una scelta importante: le etichette
Per ogni scala vengono elaborati tutti i dettagli stilistici, comprese le regole di sovrascrittura definita dai dati e, successivamente, viene renderizzata l’intera estensione in un’unica immagine, infine viene ritagliata in tasselli. In questo modo il motore PAL di QGIS posiziona le etichette una volta sola, evitando che le stesse risultino tagliate, duplicate o disallineate lungo i bordi tra tile adiacenti.
Il flusso di lavoro in due fasi
Fase A – Rendering in QGIS
- L’algoritmo produce un’immagine completa per ciascuna delle tre scale.
- Ogni immagine viene suddivisa in 36 tile PNG.
- Vengono generati i file build_cog.bat e inject_ovr.py per la fase successiva.
Fase B – Assemblaggio con GDAL. Si esegue build_cog.bat dalla riga di comando di OSGeo4W, che svolge in modalità predefinita le seguenti operazioni:
- gdal_translate: i tile PNG diventano 108 GeoTIFF georeferenziati.
- gdalbuildvrt: tre Virtual Raster, uno per scala.
- gdal_translate: tre GeoTIFF compressi, uno per scala.
- viene utilizzato il file inject_ovr.py per ottenere il COG finale, con overview reali.
Diagramma di flusso delle fasi A e B
Il raster COG così assemblato, può essere considerato un "tile server embedded" nel GeoTIFF, ma senza la necessità di un server dedicato.
Quando va rigenerato
Il COG è un’istantanea: se cambiano dati o stili, le fasi A e B vanno rieseguite, quindi conviene pianificare la rigenerazione in base alla frequenza con cui si aggiornano i dati.
I benchmark: tempi di rendering e traffico di rete
Condizioni di prova. È stato usato QgsMapRendererParallelJob su una canvas di 1920 × 1080 pixel, con 29 layer e sistema di riferimento EPSG:6708 (RDN2008 / TM33). Macchina: Dell Precision Tower 3620 (Intel Xeon E3-1245 a 3,50 GHz, 32 GB di RAM, SSD), Windows 10, QGIS 3.34.15 LTR. Rete aziendale regionale. Il traffico è stato misurato con netstat -e a intervalli di 500 ms: misura l’interfaccia di rete, quindi include anche l’eventuale altro traffico della macchina. I risultati vengono da cinque esecuzioni isolate e non sono una garanzia per ogni configurazione.
Tempi di rendering
- Media su 5 esecuzioni: 63,58 s per il progetto tradizionale, 1,29 s con il COG multiscala (circa 49,3× più veloce).
- Prima esecuzione, a cache fredda: rappresentata dalla prima coppia di istogrammi a sinistra nel grafico a barre, con 71,88 s contro 4,18 s (circa 17,2×). Qui GDAL deve aprire il file in rete e leggerne metadati e indice dei tasselli.
- Esecuzioni successive, a cache calda: il COG si assesta intorno a 0,56–0,58 s, mentre il progetto tradizionale continua a oscillare tra circa 54 e 72 s. In tali condizioni il guadagno medio raggiunge 107x (COG Multiscala) rispetto alla visualizzazione a schermo dei singoli livelli (NO-COG).
Grafico a barre dei tempi di rendering in 5 esecuzioni: 54–72 s con il progetto tradizionale, da 4,2 a 0,6 s con il COG.
Il tempo di apertura del progetto resta sostanzialmente uguale (18,25 s contro 17,49 s): il vantaggio riguarda il disegno della mappa, con un guadagno medio pari a circa 50 volte, con punte di 107 volte se si esclude il primo avvio a cache fredda.
Traffico di rete
Durante il rendering sono stati misurati circa 3.317 MB per il progetto tradizionale contro 39,6 MB con il COG (circa −99%). Durante il caricamento del progetto, 163 MB contro 113 MB (circa −30%).
| Indicatore | Progetto tradizionale | COG multiscala | Variazione |
|---|---|---|---|
| Rendering medio | 63,58 s | 1,29 s | ≈ 49,3× più veloce |
| Rendering, prima esecuzione | 71,88 s | 4,18 s | ≈ 17,2× più veloce |
| Rendering medio cache calda | 61,5 s | 0,575 s | ≈ 107× più veloce |
| Caricamento del progetto | 18,25 s | 17,49 s | sostanzialmente uguale |
| Traffico durante il rendering | 3.317 MB | 39,6 MB | ≈ −99% |
| Traffico durante il caricamento | 163 MB | 113 MB | ≈ −30% |
Il risultato è davvero uguale?
Il confronto dei tempi conta poco se le mappe prodotte con questo script non sono all’altezza delle aspettative. Quelle ottenute alle scale 1:600.00 e 1:300.000 risultano poco significative per un raffronto dei dettagli cartografici, mentre risulta conveniente confrontare due viste alla stessa scala 1:150.000 : a sinistra i 29 layer live, a destra il COG.
 |
 |
| Vista progetto con 29 layer caricati | Aspetto grafico con un solo raster COG |
Come si può notare le differenze riguardano essenzialmente le dimensioni di due etichette, una relativa al toponimo "Tolmezzo (Tumieç)" e l'altra all'idronimo "Lago di Cavazzo", dovute, essenzialmente, all'opportunità di migliorare la messa a punto delle regole di visibilità dipendenti dalla scala utilizzate nei rispettivi stili del carattere dell'etichetta.
Perché COG invece di MBTiles?
MBTiles è un formato molto diffuso per distribuire tile cartografiche, ma in questo caso il COG era il più adatto in quanto mantiene il sistema di riferimento proiettato del progetto e permette di ottenere overview a risoluzioni adatte alle scale di consultazione. Non è una scelta universale: dipende dal software di destinazione, dal sistema di riferimento richiesto, dal tipo di distribuzione e dalle esigenze di aggiornamento.
| Aspetto | MBTiles | COG multiscala |
|---|---|---|
| Sistema di riferimento | Flusso orientato a Web Mercator (EPSG:3857), con riproiezione rispetto al sistema di lavoro | Mantiene quello del progetto (qui RDN2008 / TM33) |
| Dimensione per GISDIS | circa 430 MB | circa 94 MB |
| Livelli di scala | Livelli di zoom interi (0–22) | Overview a risoluzioni scelte, adatte alle scale locali |
| Aggiornamento | Pacchetto da rigenerare ad ogni aggiornamento | Va rigenerato anche il COG (fasi A e B) |
| Standard | de-facto Mapbox, non OGC | OGC (2023) |
Limiti e avvertenze
- Il codice è un prototipo. É stato sviluppato per tentativi successivi con il contributo di Claude.ai (Sonnet 4.6) ed è stato verificato soprattutto sulle opzioni che servivano al progetto di difesa del suolo e non è stato ancora revisionato da sviluppatori esperti. Provatelo su copie dei dati, controllate i risultati cartografici e validate il comportamento prima di usarlo in produzione.
- Si tratta di una fotografia. Identificazione, selezione, interrogazione degli attributi e aggiornamento dei dati restano affidati ai layer originali, disponibili alle scale per cui è previsto il passaggio alla visualizzazione live.
- Quando conviene. La strategia è adatta ai progetti in cui la consultazione prevale sull’interazione con il singolo oggetto, per territori fino a circa 30.000 km².
Il codice, la descrizione implementativa e i test sono disponibili su GitHub, con licenza Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0):
github.com/PianeBen/Render-Multi-Scala-COG
Sulle spalle dei giganti: il valore del FOSS4G
Un pensiero di gratitudine va a chi ha costruito le basi su cui questo script si appoggia. Alcune tappe, per ricordarlo.
- gli algoritmi di proiezione in C scritti da Gerald Evenden nel 1983, oggi alla base di PROJ;
- il desiderio di Gary Sherman di avere un GIS leggero su Linux nel 2002, da cui nacque QGIS, portato alla comunità globale anche grazie a Tim Sutton;
- Martin Dobiaš, che nel 2006 aprì QGIS a Python con i binding PyQGIS;
- Frank Warmerdam, che nel 1998 iniziò a scrivere GDAL, oggi mantenuta da Even Rouault, autore anche del driver COG;
- Guido van Rossum, che nel 1989 inventò Python;
- Andrej Markov, che nel 1913 elaborò il primo «modello linguistico» analizzando la successione delle lettere nell’Evgenij Onegin di Puškin.
Gli strumenti basati su modelli linguistici possono aiutare a esplorare soluzioni e prototipi, ma non sostituiscono la verifica tecnica, i test riproducibili e il confronto con la comunità FOSS4G.
Ogni piccolo o grande traguardo è solo una tappa, sebbene limitata, frutto di attività di ricerca teorica e pratica, sviluppo di codice e condivisione globale, trasparente e nativamente Open Source : questa è la vera forza del FOSS4G.
Tutti i video degli interventi dell'evento GFOSS.it 2026 sono disponibili sulla pagina YouTube di FOSS4g.IT - OSMit 2026.
Di seguito riporto la presentazione dalla quale è stato tratto quanto sopra.
Per approfondire
- GDAL – driver COG
- GDAL – driver MBTiles
- K. Alberti (2021), GeoTIFF Compression Optimization Guide
- Cloud-Native Geo Community (2024), Cloud-Optimized GeoTIFFs – Cloud-Optimized Geospatial Formats Guide
- cogeo.org – COG ecosystem and tools
- M. Friess et al. (2023), COMTiles: A Case Study of a Cloud Optimized Tile Archive Format, ISPRS Archives, DOI: 10.5194/isprs-archives-XLVIII-4-W7-2023
- Supporto potenziato COG in QGIS 4, post su Linkedin di Salvatore Fiandaca
CC-BY Daniele Samez
Ultimo aggiornamento 29.10.2026
