Differenze tra i sistemi di riferimento EPSG 4326 e EPSG 3857

Come distinguere facilmente le coordinate geografiche da quelle piane
(Tempo di lettura 4 ')

Capita spesso di utilizzare l'EPSG 4326 come sistema di riferimento in QGIS per visualizzare le coordinate geografiche WGS84 acquisite attraverso i dispositivi di telefonia mobile o per gestire file .KML/.KMZ prodotti con GoogleEarth ovvero per il WEB Mapping con QGIS, tanto che talvolta ci si dimentica che l'EPSG:4326, basato sull'ellissoide WGS84, non è una proiezione vera e propria ma viene rappresentata planimetricamente considerando le coordinate geografiche della latitudine e della longitudine come delle coordinate cartesiane, vedasi proiezione cilindrica equidistante.

EPSG  4326 : sistema di riferimento geografico basato sull'ellissoide WGS84 , da notare l'evidente distorsione verso le alte latitudini N e S 

Se invece utilizziamo i servizi WMS come OSM o GoogleMaps (vedi plugin QuickMapService), il sistema di riferimento predefinito da QGIS viene impostato in EPSG 3857 o Web Mercator, una variante della proiezione di Mercatore, che rappresenta un sistema di coordinate proiettato dalla superficie di una sfera, approssimando la Terra a una sfera perfetta, su un cilindro tangente ad essa all'equatore. Il cilindro viene quindi srotolato per ottenere la mappa planare. Ciò introduce importanti distorsioni non solo delle aree situate in prossimità dei poli ma anche di quelle poste alle nostre latitudini, dell'ordine di h=√(1- e²sen²(φ))/cos(φ) ≅ 1/cos(φ) ovvero una distanza di 100 m misurata sulla mappa in EPSG 3857 corrisponde, alla latitudine di 46°N, a un lunghezza nella realtà di  100 / h ≅ 70 m , con un errore lineare in eccesso del 44 %  .

EPSG 3857 : la proiezione di Mercatore esagera le aree lontane dall'equatore.

Autore : Jakub Nowosad, CC BY-SA 4.0 - Fonte: https://commons.wikimedia.org/wiki/File:Worlds_animate.gif

Per questi motivi, tale sistema di riferimento risulta inadatto per effettuare misurazioni cartografiche, sebbene espresso in metri con assi (Est, Nord). Infatti, non si tratta di un sistema di riferimento autonomo ma, più propriamente, di una proiezione delle classiche coordinate ellissoidiche basate sulla latitudine e longitudine, che si potrebbe definire "simil-Mercatore". Sebbene nelle mappe di Google e OSM questa proiezione risulti applicata alle coordinate ellissoidiche (geografiche) WGS84 e quindi utilizzi come sistema di riferimento il predetto WGS84, andrebbe accuratamente evitata per operazioni metriche in quanto affetta da distorsioni geometriche significative. Risulta sostanzialmente sviluppata per semplificare la visualizzazione e consentire lo scorrimento fluido delle mappe all'interno della piccola superficie piana delimitata dallo schermo di un PC, senza la necessità di svolgere calcoli più complessi. Si potrebbe affermare che siamo in presenza di un'astuta soluzione informatica piuttosto che di una rigorosa proiezione cartografica. 

Come noto, la differenza più evidente tra coordinate geografiche, definite da una coppia di numeri che rappresentano latitudine ( φ ) e la longitudine ( λ ), mentre la quota ortometrica o geoidica h viene spesso omessa, e le coordinate piane (X o Est, Y o Nord), attenzione all'ordine degli assi che cambia a seconda delle convenzioni è che le prime vengono espresse in gradi mentre le seconde in metri e ciò risulta facilmente distinguibile nella casella Coordinata della barra di stato ( ① ) di QGIS o nelle colonne delle coordinate di un file .CSV, attraverso la seguente regola semplificata:

EPSG 4326 : utilizza un sistema di coordinate geografiche relative a una superficie curva 3D dove le misure sono espresse in gradi in modalità predefinita, quindi la parte intera delle coordinate in FVG avrà sempre due cifre, da (45,...°N 12,...°E)  a (46,...°N 14,...°E) però con molti decimali dopo la virgola (per aumentare i decimali in QGIS: Progetto➝ Propietà➝ Generali➝ Precisione coordinate➝  Manuale ➝   modificare il valore di defalut);

EPSG  4326 : l'immagine apparentemente piatta ma visibilmente deformata è in realtà la rappresentazione di un sistema di riferimento geografico 3D nel quale le misure sono angolari, qualora non definito altrimenti nella scheda Misure della proprietà del progetto.

EPSG 3857 : utilizza un sistema di coordinate proiettate su superficie piana 2D, espresse in metri, che in Regione può variare da (1285650, 5653209) a (1620541, 5918317) , quindi con la parte intera costituita da sette cifre e con assenza o pochi decimali dopo la virgola.

EPSG  3857 : sistema di riferimento pseudo-proiettato dove le misure sono espresse in metri

Premesso che tali pseudo proiezioni dovrebbero essere adottate esclusivamente per rappresentazioni di geometrie acquisite con una precisione metrica o per trasferire dati tra applicazioni per l'escursionismo, resta il fatto che per effettuare rilievi accurati in campagna si dovrebbe ricorrere a strumenti GNSS dotati di multifrequenza e correzione (N)-RTK oppure utilizzare, in via speditiva, applicazioni come QField o MerginMaps dotati di antenna GNSS esterna.

Ad ogni modo, le coordinate vanno sempre acquisite nel sistema di riferimento ETRS89/RDN2008, scegliendo come definizione del sistema di riferimento geografico (CRS)  quello più adatto al livello di accuratezza richiesto per il rilievo, l'EPSG 6706 per misure geodetiche di alta precisione su distanze estese o qualora si intende operare direttamente sull’ellissoide, mentre andrebbe utilizzato il sistema di riferimento rigorosamente proiettato EPSG 6708 ovvero RDN2008-TM33 per effettuare operazioni sul terreno fino alle distanze in cui l’errore rimane entro i limiti di tolleranza prefissati.

Infatti, nella proiezione UTM (cilindrica trasversa di Gauss), il cilindro risulta secante all’ellissoide lungo il meridiano centrale, dove la deformazione lineare o fattore di scala assume il valore 0,9996 e le misure in direzione Est-Ovest prese sul terreno si contraggono del 0,04%, mentre spostandosi verso i bordi del fuso (±3°) le distanze vengono dilatate di un fattore pari a 1,0004. Di conseguenza, se sul terreno misuriamo 10 km (limite del campo topografico) con lo strumento impostato su EPSG 6708 (UTM 33N basato su RDN2008), sulla carta otterremo 9 .996 m lungo il meridiano centrale e 10. 004 m ai margini del fuso. Le deformazioni planimetriche possono pertanto raggiungere valori di circa  ±40 cm/km.

Tenuto conto che se non si applicano correzioni aggiuntive le distanze reali misurate sul terreno si deformano sempre passando alla carta UTM o viceversa, se due punti sul terreno distano 10 km, si deve prima ridurre la distanza all'ellissoide moltiplicandola, se in corrispondenza del meridiano di riferimento, per 0,9996 e successivamente proiettarla sul piano carta con le formule geodetiche. Viceversa se la distanza tra due punti sulla carta UTM è di 10 km, prima deve essere divisa per il modulo di deformazione lineare e poi aumentata per portarla alla quota media dei due punti, per ottenere la distanza reale.

A tale proposito si segnala che per il calcolo delle aree in QGIS esistono due formule:

• $area : che restituisce l'area dell'elemento corrente calcolata sull'ellissoide impostato nella scheda Misure delle proprietà generali del progetto (Progetto ➥ Propietà ➥ Generali ). Se nessun ellissoide è stato impostato allora l’area calcolata sarà planimetrica
• area(@geometry) :  che restituisce l’area planimetrica di un oggetto geometrico poligonale, basata sul Sistema di Riferimento Spaziale (SR) di tale geometria, in cui le unità di misura dell’area restituita corrisponderanno alle unità di misura del SR .

Da notare che se una proiezione utilizza i metri come unità di misura non significa che rappresenta le aree in modo accurato, per cui se dobbiamo calcolare con precisione superfici conviene utilizzare una proiezione equiareale.

L'accuratezza degli attuali ricevitori GNSS presenti nei comuni dispositivi di telefonia mobile non consente ancora di raggiungere precisioni decimetriche, attestandosi secondo alcune fonti attorno ai 5-20 m per smartphone a singola frequenza e 3-6 m per quelli a doppia frequenza, pertanto insufficiente per apprezzare le differenza tra un SR non agganciato come l'EPSG 4326 e uno solidale alla placca europea come l'EPSG 6706. Tale situazione potrebbe cambiare grazie alla graduale attivazione, a partire dal gennaio 2023, del servizio Galileo E6-B (High Accuracy Service), tuttavia, per poterle apprezzare bisognera attendere la disponibilità sul mercato di smartphone capaci di elaborare il nuovo segnale E6-B ad alta precisione per il posizionamento preciso dei punti (PPP).

Fonti:

1. https://frednet.crs.ogs.it/immagini/_notes/Beinat2009.pdf

2. http://labtopo.ing.unipg.it/files_sito/aurelio/Tutorial%20Reti%20GNSS_2_finale.pdf
3. https://it.wikipedia.org/wiki/Proiezione_cilindrica_centrografica_modificata_di_Mercatore
4. https://www.hydrometronics.com/downloads/Web%20Mercator%20-%20Non-Conformal,%20Non-Mercator%20(notes).pdf
5. https://gis.stackexchange.com/questions/48949/epsg-3857-or-4326-for-web-mapping

6. https://gis.stackexchange.com/questions/426682/displaying-wgs-84-epsg4326-coordinate-grid-over-epsg3857-map-in-qgis

7. https://en.wikipedia.org/wiki/Mercator_projection

8. https://www.iogp.org/wp-content/uploads/2019/09/373-07-02.pdf

CC-BY-Daniele Samez 

Aggiornato in data 18.10.2026

GeoPackage, Shapefile e dintorni.

GeoPackage, Shapefile e dintorni. Caratteristiche, comparazioni, benchmark e relativi ambiti di utilizzo in QGIS.
(Tempo di lettura 9 ')

In questo post vengono riportate alcune considerazioni sulle differenze strutturali e prestazionali nell'utilizzo del formato GeoPackage in QGIS, non solo rispetto al maturo Shapefile ma anche nei confronti dei formati SpatiaLite e GeoJSON, accomunati dal fatto di essere database spaziali standalone (1), ovvero che non richiedono un server per funzionare.

In linea di massima il GeoPackage (2) può essere definito come un formato aperto per la memorizzazione di dati geospaziali racchiusi in un singolo file con estensione .gpkg. 

La struttura, costruita sullo schema del database SQLite3 (3) e nel rispetto della codifica standard definita dall’OGC (Open Geospatial Consortium) (4), rende il formato GeoPackage capace di contenere più livelli di dati vettoriali (5), immagini raster, indici spaziali, stili dei layer e altri tipi di tabelle senza geometrie associate, come ad esempio i metadati e perfino lo stesso progetto QGIS, il tutto in un singolo file che può essere scambiato facilmente anche tra computer con processori e sistemi operativi diversi (concetto di interoperabilità). Consente l'accesso simultaneo in lettura da parte di più utenti, mentre nel caso si debba ricorrere alla scrittura (editing) condivisa andrebbero preferiti altri formati più adatti alla modifica collaborativa di dati geospaziali.

Progettato per gestire archivi complessi e dati voluminosi fino a 140 TByte (6), il GeoPackage permette di superare alcuni limiti anacronistici dello Shapefile (nato nell’epoca del MS-DOS), tra cui i 10 caratteri per i nomi delle intestazioni dei campi, quello dei 255 caratteri per gli attributi testuali e la soglia dei 2 Gbyte per i file. Per di più, gestisce correttamente i campi data+ora (DateTime) ed applica diversi vincoli di integrità che proteggono il database da cancellazioni e altri danni accidentali (ma non vi prepara il caffè in quanto non è strutturato per gestire accessi simultanei in modifica o assegnare permessi in lettura o scrittura ed inoltre essendo solo un contenitore di database, non gestisce le query e non effettua le altre operazioni topologiche sui database che invece devono essere eseguite tramite software per l’analisi spaziale come QGIS).

Sebbene QGIS poteva già con la versione 2.10.1 leggere e scrivere file in formato GeoPackage e successivamente con la versione 2.18 leggere anche Tiles, benché con importanti limitazioni, l’integrazione definitiva è avvenuta con il rilascio, nel febbraio del 2018, della versione 3.0 di QGIS, nella quale le impostazioni predefinite per operare sui layer vettoriali sono passate dal proporre il formato Shapefile a quello GeoPackage.

Questo cambiamento non dovrebbe spaventare chi è abituato a lavorare con i layer Shapefile, sempre presenti in QGIS nell’elenco dei formati disponibili, ma piuttosto rappresenta un invito ad avvalersi, per l’interscambio dei dati geospaziali, di un formato tecnologicamente più evoluto e in continuo aggiornamento , che contiene in un unico file geometrie vettoriali, dati tabellari e livelli raster, mentre lo Shapefile, come noto, può memorizzare solo layer vettoriali utilizzando almeno 3 file distinti.

Come già accennato, la principale differenza, a livello macroscopico, che si può osservare affiancando una cartella contenente un layer salvato nel formato Shapefile con una contenente lo stesso layer ma in formato GeoPackage è che nella prima ci saranno almeno 3 file, con estensione .shp, .dbf, .shx e forse molti altri con estensioni diverse, mentre nella seconda sarà presente un solo file con estensione .gpkg , come schematizzato nella seguente figura esplicativa :

Risulta opportuno, a questo punto, fare un breve cenno sul formato SpatiaLite che esteriormente presenta una forte somiglianza con il GeoPackage in quanto entrambi risultano costituiti da un unico file e condividono lo stesso “motore” SQLite (7) ma, a parte queste caratteristiche comuni, appartengono a due categorie funzionalmente distinte. Il GeoPackage è in sostanza un contenitore di database come il suo antenato Shapefile, mentre lo SpatiaLite include sia le librerie SQL che le estensioni per gestire i dati geospaziali e ciò rende tale formato indipendente dall'applicativo GIS utilizzato, per cui in specifici ambiti operativi potrebbe costituire, secondo un’autorevole fonte, una valida alternativa standalone rispetto a formati client-server come PostgreSQL/PostGIS o per altri Spatial DBMS .

Per avere un’ordine di grandezza delle differenti dimensioni dei file memorizzati e dei tempi di caricamento di uno o più layer vettoriali salvati nei formati Shapefile, GeoPackage, SpatiaLite e GeoJSON, sono stati effettuati alcuni test speditivi, svolti esclusivamente con gli strumenti di processing e di misura presenti in QGIS (8), al fine di determinare i valori medi relativi a tre caricamenti per ciascuno dei tre dataset utilizzati per la prova comparativa, il primo riguarda il layer dei confini dei Comuni del FVG 2021 contenente  215 poligoni con 7 attributi, il secondo è il classico Corine Land Cover (CLC18_IVLIV_IT), contenente un layer di 136.391 poligoni con 4 attributi e l’ultimo composto da 57 layer e da tre diversi tipi di geometrie, 4 layer contenenti 498.323 punti, 15 layer con 177.115 linee e 38 layer con 644.357 poligoni che costituiscono il dataset DBTfvg Lotto Giuliano (shape_DBT_TS_V20201124). La configurazione del sistema di prova era composta da un PC Dell Precision Tower 3620 (CPU Intel Xeon E3-1245 @ 3.50GHz, RAM 32 GB, SSD) con sistema operativo Windows 10 (Ver. 2009) e QGIS versione 3.22.10 LTR .

Formato database	N. geometrie e tipo	Totale MByte	N. file	Var. % dim.shp	Tempo (s) layer sorgente/mappa	Var. rel. vel.shp
Shapefile FVG	125 Polygon	20	4	0%	0,02133	1,00
GeoPackage FVG	125 Polygon	20,1	1	0,5%	0,01433	1,49
SpatiaLite FVG	125 Polygon	26,4	1	32%	0,01067	2,00
GeoJSON FVG	125 Polygon	65,5	1	227%	11,779	0,00181
Shapefile CLC	136.391 Polygon	265	8	0%	0,01967	1,00
GeoPackage CLC	136.391 Polygon	306	1	15%	0,01167	1,69
SpatiaLite CLC	136.391 Polygon	313	1	18%	0,01033	1,90
GeoJSON CLC	136.391 Polygon	753	1	184%	143,692	0,00014
Shapefile DBT_TS	498.323 Point	2.800	667	0%	0,966	1,00
	177.115 Line
	6443.57 Polygon
GeoPackage DBT_TS	498.323 Point	1.017	1	-64%	1,42	0,68
	177.115 Line
	644.357 Polygon
SpatiaLite DBT_TS	498.323 Point	838	1	-70%	0,295	3,27
	177.115 Line
	644.357 Polygon
GeoJSON DBT_TS	498.323 Point				Test non effettuato
	177.115 Line
	644.357 Polygon

A prescindere dalle maggiori funzionalità offerte dall’uno o dall'altro formato, ciò che balza subito agli occhi scorrendo i risultati tabellati nella colonna "Var. % dim.shp", relativa all'indice di variazione dimensionale in MB rispetto allo Shapefile, è la minore occupazione di spazio su disco del formato Shapefile per dataset fino a circa 300 MByte, mentre nel caso del dataset composto da 57 Shapefile con 667 file e una dimensione totale di 2.800 MByte, si osserva una riduzione di circa ⅔ delle dimensioni del dataset passando ai formati più recenti GeoPackage e SpatiaLite.

Risultati più interessanti, invece, quelli riportati nell'ultima colonna "Var. rel. vel.shp", che rappresenta una sorta di “velocità” di caricamento del formato in esame rispetto a quella base dello Shapefile e costituisce un indice prestazionale, migliore se superiore all’unità o peggiore se inferiore. In termini più precisi, esprime il rapporto tra il tempo di caricamento del layer Shapefile sorgente, se unico, o dei layer Shapefile della mappa, se molteplici, e il tempo impiegato per caricare il dataset nel relativo formato, sempre misurato in secondi con l'apposito strumento di QGIS .

Il gradino più alto sul podio, con il minor tempo di caricamento dei dataset per ognuna delle 3 prove , risulta stabilmente occupato dal formato SpatiaLite, che vanta anche un ottimo piazzamento relativamente alle dimensioni del file generato, mentre il formato GeoPackage ottiene il secondo posto per dataset fino a circa 300 MB mentre, nel caso del dataset del DBT_TS, manifesta un comportamento anomalo piazzandosi, inaspettatamente, addirittura dietro allo Shapefile (anche ripetendo il test in altre condizioni) . Al quarto e ultimo posto si piazza, per l'eccessivo spazio occupato dal file e per la lenta "velocità" di caricamento, il dataset in formato GeoJSON, che però risulta più orientato alle applicazioni WEB.

Anche se non può certo definirsi statisticamente rappresentativo un test speditivo eseguito con 3 dataset su un solo PC e con un'unica versione di QGIS, si tratta comunque di una prima misura sperimentale. Ad ogni modo, per chi volesse cimentarsi in simili prove, i dataset necessari possono essere liberamente scaricati presso i riferimenti riportati alla fine di questo post (9)(10)(11).

In merito all’annosa questione della transizione dal formato Shapefile a quello GeoPackage, ritengo che forse potrebbe non avvenire del tutto, almeno non con modalità così pervasive come ci si aspettava, in quanto vi sono diversi settori produttivi e amministrativi, che svolgono prevalentemente attività diverse dalla cartografia o geomatica, nelle quali lo Shapefile risulta, a tutti gli effetti, più che sufficiente per sopperire alle circoscritte esigenze di rappresentazione dei dati territoriali relativi a piccole realtà locali o a quelle progettuali per opere pubbliche di modesta entità.

Riporto una breve esemplificazione che spero possa chiarire meglio le criticità che possono verificarsi in alcuni ambiti operativi. Tra le complesse attività di validazione tecnica e normativa del progetto di un intervento redatto da terzi, una parte riguarda la verifica degli elaborati grafici allegati. Talvolta, nonostante l’indicazione di produrre file vettoriali territoriali in formato Shapefile con S.R. RDN2008/TM33 (EPSG6708), può capitare di riceverli in formato .DWG o .DXF, talora non georiferiti o ancora in Gauss Boaga, ma anche in questi casi non conviene lamentarsi troppo in quanto può accadere di scoprire che tutti gli elaborati grafici pervenuti sono esclusivamente in formato .PDF, bloccati in modifica e copia, però rigorosamente firmati digitalmente.

Va detto inoltre che i geopacchetti (termine talvolta utilizzato al posto di GeoPackage), se da un lato offrono numerose caratteristiche e funzionalità avanzate, dall’altro richiedono un certo grado di padronanza nella gestione di più database in un unico contenitore e la conoscenza di alcuni concetti non banali la cui curva di apprendimento potrebbe rappresentare un limite in molti ambiti operativi non strettamente centrati sulle esigenze specifiche della cartografia digitale.

Non va neppure sottovalutata la complessità della struttura del formato GeoPackage, la cui corretta gestione da parte del sistema è di fondamentale importanza per mantenere l’integrità del database geospaziale e qualora venisse compromessa potrebbero verificarsi sporadici inconvenienti, come ad esempio l’impossibilità di modificare la cella di una tabella durante l’editing o altre criticità. Nella remota ipotesi che ciò si verifichi durante una modifica non simultanea della tabella attributi, la soluzione consigliata è quella di creare in QGIS un nuovo profilo o cancellare quello di default e riavviare l'applicativo. Sembra che tale rarissima anomalia sia da attribuire a delle configurazioni sbagliate fatte involontariamente dall’utente oppure all’installazione di plugin difettosi (NdR con il beneficio del dubbio, alcuni nerd sostengono che ciò capiti solo a chi utilizza Windows come sistema operativo mentre sulle versioni Linux si dice che queste cose non accadono).

Per quanto detto sopra, ritengo sia più probabile il raggiungimento di una situazione di pacifica coesistenza tra i due formati standalone, nella quale lo Shapefile potrebbe continuare ad essere utilizzato per archiviare singoli database territoriali con strutture semplici e di dimensioni contenute, mentre il GeoPackage potrebbe essere dedicato alla gestione di database geospaziali con strutture complesse che non richiedono accessi simultanei in modifica. Il formato SpatiaLite, invece, andrebbe preferito nei casi in cui sia richiesta un’elevata velocità di caricamento di dataset particolarmente voluminosi oppure per risolvere eventuali criticità riscontrate in fase di modifica dei geopacchetti.

In ogni caso tra le FAQ del sito GeoPackage.org, che è il sito di riferimento per tale formato, si legge la seguente risposta alla domanda se il GeoPackage sostituirà lo Shapefile: “Potrebbe ma non è necessario. Se tutto ciò di cui hai bisogno è semplicemente trasferire o visualizzare, il formato GeoPackage potrebbe essere eccessivo e qualcosa come GeoJSON potrebbe essere più appropriato… “, ma avrei qualche dubbio nell'adoperare il formato GeoJSON per l’interscambio di dati geospaziali, visti gli esiti dei test effettuati.

Comunque, trattandosi di punti di vista personali e soggettivi ognuno è libero di nutrire aspettative e convinzioni differenti rispetto a quelle sopra esposte (clausola liberatoria), per il resto ritengo sia meglio lasciare che siano le scelte fatte dai singoli utenti, nel corso di un congruo lasso di tempo, a dirimere la questione.

Altri tipi di analisi delle prestazioni che riguardano i tempi di esecuzione di alcune query spaziali sono consultabili sulle pagine riportate nei punti (12), (13), (14), mentre ai punti (15) e (16) sono riportati i link a due articoli che avevano affrontato in precedenza il tema dei vantaggi del formato GeoPackage rispetto allo Shapefile.

Fonti:

1. L’alternativa all'architettura standalone, è rappresentata dai database client-server, come PostgreSQL/PostGis, che per lavorare richiedono l’accesso, da uno o più terminali client, a un server dedicato alla gestione degli accessi, all’aggiornamento dei dati e al controllo della loro integrità.

2. http://www.geopackage.org/guidance/getting-started.html

3. https://it.wikipedia.org/wiki/SQLite

4. https://www.ogc.org/standard/geopackage/

5. Per dati vettoriali si intendono quelle geometrie composte da punti o linee o poligoni e dai relativi attributi visualizzati in tabelle organizzate in righe, chiamate record e in colonne, chiamate campi.

6. http://www.GeoPackage.org/spec/

7. A voler essere precisi, l’SQLite è un DBMS non geografico di tipo standalone mentre PostgreSQL/PostGis è uno Spatial DBMS, cioè è in grado di svolgere, al suo interno, elaborazioni geografiche oltre a quelle tabellari, oltreché funzionare in modalità client-server. 

8. https://www.qgis.org/en/site/forusers/visualchangelog316/index.html#id65

9. Dataset Comuni FVG 2021 :   https://irdat.regione.fvg.it/consultatore-dati-ambientali-territoriali/home

10. Dataset CLC :  https://groupware.sinanet.isprambiente.it/uso-copertura-e-consumo-di-suolo/library/copertura-del-suolo/corine-land-cover/corine-land-cover-2018-iv-livello

11. Dataset DBT_TS :  https://eaglefvg.regione.fvg.it/eagle/main.aspx?configuration=Guest

12. https://github.com/pigreco/benchmark/blob/master/prove/estrai_vertici.md

13. https://www.gaia-gis.it/fossil/libspatialite/wiki?name=benchmark-4.0

14. https://oslandia.com/en/2019/06/21/qgis-3-and-performance-analysis/

15. https://pigrecoinfinito.com/2018/04/08/qgis-e-il-formato-GeoPackage/

16. https://massimilianomoraca.it/blog/gis/il-geopackage-una-valida-alternativa-al-formato-shape/

 </

CC-BY-Daniele Samez 

N.d.R. Per la stesura di questo scritto non si è fatto uso di strumenti di A. I. e ciò può essere facilmente desunto dalla presenza di numerose imperfezioni e imprecisioni nel testo di cui sopra ;-).