Ottimizzare progetti QGIS su LAN: un procedimento sperimentale per rendere più reattivi i progetti cartografici condivisi in rete
(Tempo di lettura 9 ')
Contenuto in sintesi
- Da dove nasce il problema: un progetto QGIS, caratterizzato da un’elevata integrazione e dotazione informativa, 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 codice 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 scritto descrive la soluzione presentata a Trento nel corso dell’evento FOSS4G-IT & OSMit 2026.
Glossario sintetico per gli apprendisti in ambito GIS
- COG (Cloud Optimized GeoTIFF): è un formato raster simile al GeoTIFF organizzato internamente in modo d permettere letture selettive.
- Tile (tassello): è la 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 fonde più raster senza duplicarli.
- PAL (Placement Automatique de Légendes o Placement Algorithm): il motore di etichettatura di QGIS.
- Cache fredda / calda: alla prima lettura del file, GDAL deve aprire il raster e leggerne i metadati (cache fredda o “cold cache”), mentre nelle successive, parte di queste informazioni sono già in memoria (cache calda o “hot cache”).
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 di opere di difesa del suolo nella Regione Autonoma Friuli Venezia Giulia. Si tratta di un ecosistema informativo geografico che estende le funzionalità native di QGIS attraverso una logica customizzata per mezzo di codice PyQGIS, abilitando l'accesso a servizi API remoti e il recupero in tempo reale di foto, relazioni conservate su server SharePoint, dati OpenCUP e servizi WMS (PGRA, catasto, ortofoto IRDAT, ISPRA). Comprende oltre 60 layer vettoriali tematizzati, 29 dei quali visibili alla scala di apertura, raster (ortofoto, HillShade) e un rilievo ombreggiato a tinte ipsometriche (Colored Shaded Relief) di sfondo.
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 rete condivisa NTFS : in tale circostanza il trasferimento dei dati dal server al client risulta vincolato dalla larghezza di banda. La causa più probabile è riconducibile al volume dei dati che transitano sulla rete condivisa da tutta la struttura regionale e che porta ad un aumento della latenza tale da rendere poco reattiva la navigazione cartografica.
Non essendo possibile ridurre il numero di layer né semplificare il progetto, si è cercato di ridurre il lavoro computazionale necessario per mostrare la mappa alle scale più usate, spostando una parte dell’elaborazione dalla fase di consultazione a una fase di preparazione.
La strategia adottata: due componenti invece di una sola
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 costituita dalla sovrapposizione dei layer visibili all’apertura della mappa.
- 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, pertanto misurano l’effetto combinato delle due soluzioni parziali, non solo quella del contributo del formato COG.
A sinistra il client QGIS che legge in rete 29 layer e servizi WMS; a destra il client che legge pochi tasselli da un solo COG.
Cosa viaggia sulla rete prima e dopo l’ottimizzazione.
COG e GeoTIFF classico: che cosa cambia
Il COG non è un formato nuovo: è simile al 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 shell 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 1:600.000 / 1:300.000 / 1:150.000
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 superare parzialmente ciò, nel progetto GISDIS FVG sopra il raster COG viene caricato un layer puntuale, contenente i singoli interventi di difesa del suolo, interrogabile per ciascuna opera realizzata. Per esigenze espositive, tale strato informativo risulta escluso dalla presente trattazione.
Quando deve mostrare una vista, il client non legge l’intero livello: GDAL individua i tasselli che intersecano l’estensione e la scala correnti e chiede solo i loro byte. Da un server web sono richieste HTTP «Byte-Range»; su una condivisione di rete come quella regionale sono letture parziali del file. 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 prende l’estensione da un layer di riferimento (o da un’estensione manuale), applica i parametri predefiniti riportati nella tabella più sotto, comunque modificabili nella finestra di dialogo 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 DPI |
| 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 viene renderizzata l’intera estensione in un’unica immagine e solo dopo la ritaglio in tasselli. In questo modo il motore PAL di QGIS posiziona le etichette una volta sola, e si evita che 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 lancia build_cog.bat dalla Shell di OSGeo4W)
- gdal_translate: i tile PNG diventano 108 GeoTIFF georeferenziati.
- gdalbuildvrt: tre Virtual Raster, uno per scala.
- gdal_translate: tre GeoTIFF compressi, uno per scala.
- inject_ovr.py: il COG finale, con overview reali.
Diagramma di flusso delle fasi A e B
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: 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: il COG si assesta intorno a 0,56–0,58 s, mentre il progetto tradizionale continua a oscillare tra circa 54 e 72 s. La media di 1,29 s del COG include la prima esecuzione a freddo.
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 |
| 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 la mappa prodotta con questo script non è all’altezza. Ecco le due viste a confronto alla stessa scala: a sinistra i 29 layer live, a destra il COG.
 |
 |
| Vista progetto con 29 layer caricati | Aspetto grafico con un solo raster COG |
Perché COG invece di MBTiles?
MBTiles è un formato molto diffuso per distribuire tile cartografiche, ma in questo caso il COG era più adatto per i motivi riportati nella colonna "COG multiscala". 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
Questo risultato poggia su decenni di lavoro condiviso. 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 gli interventi del GFOSS.it di Trento 2026 possono essere visti sulla pagina YouTube di FOSS4g.IT - OSMit 2026, mentre di seguito viene riportata la presentazione alla presente tematica.
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
Daniele Samez · lavoro presentato al FOSS4G-IT & OSMit 2026, Trento
Nessun commento:
Posta un commento