QGIS regge decine di milioni di elementi, ma la tabella attributi è il punto dove la fluidità si perde per prima: la apri su un layer grande e tutto rallenta. Il motivo è che la tabella non mostra solo i dati: li interroga, li ordina e li aggiorna in continuazione, e ogni elemento in più moltiplica il lavoro. Le cause sono quasi sempre le stesse, e le soluzioni pure.
Le cause più comuni
La prima è il formato del dato. Uno shapefile o un CSV con centinaia di migliaia di righe obbliga QGIS a lavorare in modo più lento di un GeoPackage o di un database spaziale. La seconda è la modalità di modifica: con il layer in editing, QGIS tiene aperto un canale di scrittura che rallenta ogni operazione. La terza sono i join e i campi calcolati al volo: un join su una tabella enorme si ricalcola a ogni apertura. La quarta è la tabella sempre aperta in background: chiudere la finestra non basta se il pannello continua ad aggiornarsi. La quinta sono i campi inutili: dieci colonne che non guardi mai pesano su ogni ordinamento e filtro.
Le soluzioni, in ordine di impatto
La soluzione con l'impatto maggiore è spostare il dato in un database. PostGIS è la scelta seria, ma anche un GeoPackage locale, con indice spaziale, cambia le cose rispetto a uno shapefile. La seconda è uscire dalla modalità di modifica quando non serve: si attiva solo per editare, mai per consultare. La terza è filtrare: un filtro sul fornitore dati o una selezione riducono le righe che la tabella deve gestire. La quarta è alleggerire i join, materializzando i risultati quando il join serve solo una volta. La quinta è pulire i campi: rimuovere le colonne morte si fa in un minuto e paga su ogni sessione.
I controlli da fare subito
Apri le proprietà del layer e guarda tre cose: il formato sorgente, il numero di campi e la presenza di join o campi virtuali. Se il layer è uno shapefile con quaranta campi e tre join, il problema è lì, non nel tuo computer. Poi prova il test che separa il software dal dato: apri lo stesso layer su un progetto vuoto. Se è lento anche lì, è il dato; se è veloce, è il progetto, e la colpa è di qualche configurazione o plugin che appesantisce la sessione.
Il principio che evita il problema alla radice
La regola da portarsi a casa: i dati grandi non si tengono in formati da scambio. Shapefile e CSV servono a trasportare, non a lavorare. Appena un layer supera qualche decina di migliaia di elementi, lo si porta in GeoPackage o PostGIS, con indice spaziale, e la tabella attributi torna a rispondere. Noi lavoriamo ogni giorno con layer ben oltre quei volumi: 85 milioni di particelle catastali in PostGIS 3.3 su PostgreSQL 15, con una dozzina di tabelle di arricchimento da decine di milioni di righe l'una. La tabella principale pesa 200 GB su un database da 622 GB complessivi, visibili sulla mappa catastale. La differenza tra formato giusto e sbagliato, a quelle dimensioni, è la differenza tra lavorare e aspettare.
Foto di copertina: Daniil Komov su Pexels