GeoParquet vs. GeoJSON: Quale formato GIS è migliore per grandi dataset?

Se hai mai provato ad aprire un file GeoJSON da 2 GB in QGIS o a caricare un file di confini poligonali con milioni di righe in una mappa interattiva, conosci già la sensazione di affondamento di uno schermo bloccato e di un crash per mancanza di memoria.

Per più di un decennio, GeoJSON è stato la lingua franca universale della cartografia web. È trasparente, leggibile dall’uomo e supportato subito da quasi tutte le librerie di mappatura web e le API REST su internet.

Tuttavia, i flussi di lavoro GIS moderni appaiono radicalmente diversi rispetto al 2008. I professionisti della geospazialità di oggi ingeriscono regolarmente gigabyte (o terabyte) di telemetria di mobilità IoT, impronte edilizie a livello nazionale, maschere di segmentazione derivanti da satelliti e griglie climatiche ad alta frequenza.

Quando viene applicato a dataset di questa scala, GeoJSON non si limita a rallentare: crea un collo di bottiglia completo nelle architetture dei dati.

Entra in gioco GeoParquet, un’estensione geospaziale aperta e standardizzata per Apache Parquet in incubazione all’interno dell’Open Geospatial Consortium (OGC).

In questa guida completa, confrontiamo GeoParquet e GeoJSON in termini di architettura, efficienza di archiviazione, throughput di lettura/scrittura, prontezza al cloud e ergonomia per gli sviluppatori per rispondere a una domanda cruciale: Quale formato dovresti scegliere per grandi dataset?

1. Architettura Strutturale: Testo vs. Binario a Colonne

Per capire perché questi formati si comportano così diversamente su larga scala, devi guardare sotto il cofano a come ciascuno rappresenta i valori delle coordinate e i metadati tabulari.

+--------------------------------------------------------------+
| Metrica di valutazione |
| **Formato dei Dati** |
| **Rappresentazione geometrica** |
| **Rapporto di compressione** |
| **Proiezione di colonna** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Pushdown del predicato spaziale** |
| **Archiviazione di oggetti cloud (S3/GCS)** |
| **Leggibilità umana** |
| **Supporto del browser web** |
| **Ente di standardizzazione** |
+--------------------------------------------------------------+

GeoJSON: Orientato alle Righe, JSON Codificato in Testo

GeoJSON rappresenta i dati come un array di oggetti JSON. Ogni singola feature ripete esplicitamente le chiavi degli attributi accanto a un array di numeri in virgola mobile codificati come stringhe:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

Poiché GeoJSON è basato su testo:

• Schemi Ripetitivi: Nomi di campo come \"properties\", \"type\" e \"coordinates\" vengono ripetuti milioni di volte, gonfiando le dimensioni grezze del file.
• Conversione Costosa da Stringa a Float: La tua CPU deve analizzare i caratteri di testo (\"-\", \"9\", \"7\", \".\", \"7\"...) in float a doppia precisione IEEE a 64 bit prima di eseguire qualsiasi operazione spaziale.
• Requisiti di Lettura Monolitici: I parser JSON standard devono caricare l’intero file in memoria per costruire il Document Object Model (DOM). Leggere un singolo attributo richiede l’analisi di ogni singola feature.

GeoParquet: Orientato alle Colonne, Dati Codificati in Binario

GeoParquet si basa direttamente su Apache Parquet, memorizzando le tabelle spaziali colonna per colonna anziché riga per riga.

Attributi come county sono memorizzati in blocchi contigui, consentendo tecniche di compressione avanzate come la codifica a lunghezza di corsa (RLE), il bit-packing e la compressione a dizionario. I dati geometrici sono standardizzati come Well-Known Binary (WKB), accompagnati da metadati JSON incorporati che descrivono i sistemi di riferimento spaziali (CRS), le bounding box e i tipi di geometria.

Poiché GeoParquet è binario e colonnare:

• Costo di parsing delle coordinate zero: Le geometrie sono memorizzate direttamente in forma binaria, evitando costose conversioni da stringa a float.
• Spinta della proiezione: Se il tuo flusso di lavoro a valle richiede solo le colonne county e pop_density, il lettore recupera solo quegli offset di byte dal disco o da S3, saltando completamente la colonna della geometria.
• Partizionamento per Row-Group: I file Parquet dividono i record in “Row Groups” autonomi (spesso da 100.000 a 1.000.000 di righe ciascuno) completi di statistiche min/max per ogni colonna.

2. Confronto Diretta: Le Metriche Principali

3. Efficienza di Archiviazione e Benchmark delle Dimensioni dei File

Quando si passa da migliaia a milioni di record, le disparità di archiviazione si ampliano notevolmente.

Nei benchmark standard che utilizzano record spaziali aperti del mondo reale (come le impronte degli edifici di OpenStreetMap, i confini TIGER del censimento statunitense e i log AIS globali delle navi), GeoParquet ottiene regolarmente riduzioni di archiviazione dal 70% all'85% rispetto al GeoJSON grezzo, e supera .geojson.gz di un ulteriore 20% al 40%.

Perché GeoParquet è così tanto più piccolo?

1. Dictionary Encoding: Gli attributi stringa ripetuti (ad es., codici di stato, classificazioni di uso del suolo) vengono indicizzati in piccoli puntatori interi anziché memorizzati ripetutamente come lunghe stringhe.
2. Compact Binary Coordinates: Un punto 2D in GeoJSON occupa circa 30‑45 byte di testo ASCII ([-122.4194155, 37.7749295]). In WKB, la stessa coppia di coordinate richiede esattamente 16 byte.
3. Modern Compression Algorithms: Zstandard (Zstd) e Snappy comprimono gli array di byte colonnari molto più efficacemente rispetto a quanto Gzip standard possa comprimere testo basato su righe intercalate.

4. Prestazioni delle Query e Flussi di Lavoro Cloud-Nativi

Il fattore distintivo più importante per i grandi dataset non è solo lo spazio di archiviazione—è la latenza delle query e l’utilizzo della memoria.

1. Letture Selettive tramite Proiezione di Colonna

Immagina un dataset nazionale di particelle da 15 GB contenente 60 attributi (nomi dei proprietari, codici fiscali, cronologia dei titoli, codici di zonizzazione e confini multipoligonali complessi).

• In GeoJSON: Se vuoi calcolare il valore medio stimato della proprietà per codice postale, il tuo motore analitico deve scaricare e analizzare tutti i 15 GB, inclusi milioni di vertici di confine complessi.
• In GeoParquet: I motori analitici come DuckDB, Apache Sedona, Polars o AWS Athena leggono solo le colonne zip_code e assessed_value. Invece di trasferire 15 GB, il tuo motore scarica e analizza meno di 80 MB.

2. Richieste HTTP Range su Cloud Storage

GeoParquet funziona senza problemi come un formato geospaziale cloud‑native.

Poiché i file Parquet memorizzano offset interni e metadati nel loro footer, le librerie client possono inviare richieste HTTP GET Range: bytes=... ai cloud object store come Amazon S3, Google Cloud Storage o Azure Blob Storage. Invece di scaricare un intero file multi‑gigabyte, il client legge il footer, identifica gli offset di byte esatti in cui si trovano i record rilevanti e scarica solo i sottoinsiemi necessari.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. Ecosistema software e supporto degli strumenti

Storicamente, il principale vantaggio di GeoJSON era il supporto universale degli strumenti. Sebbene ciò rimanga vero per gli ambienti browser, l’ecosistema di GeoParquet è maturato rapidamente:

• Desktop GIS: Supporto nativo di lettura/scrittura in QGIS 3.28+, ArcGIS Pro e GDAL/OGR 3.5+.
• Motori analitici e linguaggi: Capacità di lettura/scrittura vettoriale veloce su Python (GeoPandas, pyarrow), R (sf), DuckDB (tramite l’estensione spaziale), Apache Sedona e Snowflake.
• Pipeline Big Data: Integrazione nativa con Apache Spark, Trino, Presto e Databricks.
• Mappe web lato client: Le librerie WebAssembly leggere (come parquet-wasm e duckdb-wasm) ora consentono ai browser web di interrogare i file GeoParquet direttamente sui dispositivi client senza un server middleware GIS dedicato.

6. Matrice decisionale pratica: quando usare quale?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

Scegli GeoJSON se:

• Il tuo dataset è inferiore a 50 MB fino a 100 MB.
• Stai restituendo risposte payload leggere da un’API REST ai client frontend.
• Stai creando mappe web leggere utilizzando Leaflet, MapLibre o Mapbox GL JS senza livelli di traduzione intermedi.
• Hai bisogno di modifiche o ispezioni manuali rapide in un editor di codice o di testo standard.

Scegli GeoParquet se:

• Il tuo set di dati supera i 100 MB, o contiene centinaia di migliaia di caratteristiche spaziali complesse.
• Stai archiviando risorse vettoriali in uno storage di oggetti cloud (S3, GCS, MinIO, Azure Blob).
• Esegui analisi SQL spaziali, feature engineering o pipeline di machine learning usando Python, DuckDB, Spark o Databricks.
• Vuoi ridurre i costi di archiviazione, evitare le tariffe di uscita di rete e eliminare i crash di memoria.

7. Esempio di migrazione: conversione da GeoJSON a GeoParquet

Convertire le risorse spaziali esistenti in GeoParquet richiede solo poche righe di codice.

Utilizzare Python (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

Utilizzare GDAL / OGR (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

Utilizzare DuckDB

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. Riepilogo: Il Verdice sui Grandi Dataset

Per piccoli set di dati e endpoint web diretti, GeoJSON rimane un formato di utilità affidabile e senza problemi.

Tuttavia, per grandi set di dati, GeoParquet è oggettivamente superiore in ogni categoria operativa. Offre dimensioni di file più ridotte, un overhead di archiviazione significativamente più basso, letture spaziali quasi istantanee e integrazione nativa con i moderni data warehouse cloud.

Se le tue pipeline geospaziali stanno gemendo sotto il peso di file GeoJSON sovradimensionati, passare a GeoParquet è uno degli aggiornamenti infrastrutturali più efficaci che puoi effettuare.

Domande frequenti (FAQ)

Q1. GeoParquet è uno standard GIS ufficialmente riconosciuto? Sì, GeoParquet è uno standard aperto ufficiale mantenuto sotto la guida del Open Geospatial Consortium (OGC).

Q2. Posso visualizzare un file GeoParquet direttamente nelle librerie di mappatura web come Leaflet o Mapbox GL JS? Sebbene non venga analizzato nativamente come GeoJSON, è possibile visualizzare GeoParquet nei browser usando pacchetti WebAssembly come parquet-wasm o convertendo i file in Vector Tiles (PMTiles/MVT) durante l’ingestione.

Q3. GeoParquet supporta più sistemi di riferimento di coordinate (CRS)? Sì, a differenza di GeoJSON (che è strettamente limitato a WGS 84 / EPSG:4326 secondo l’RFC 7946), GeoParquet consente definizioni CRS personalizzate direttamente all’interno dei metadati incorporati del file.

Q4. Come si confronta GeoParquet con FlatGeobuf per grandi dataset spaziali? FlatGeobuf è ottimizzato per lo streaming di feature spaziali direttamente su mappe web interattive usando l’indicizzazione spaziale R-Tree, mentre GeoParquet è progettato per analisi colonnari ad alte prestazioni, compressione e archiviazione massiva in data lake.

Q5. Posso aprire file GeoParquet all’interno di software GIS desktop come QGIS? Sì, le versioni moderne di QGIS (versione 3.28 e successive) supportano il trascinamento, il rilascio, la visualizzazione e la stilizzazione dei file GeoParquet senza richiedere plugin di terze parti.

Vedi anche

Formati di file GIS su FileFormat.com

I 5 migliori formati di file GIS per Google Maps

Notizie sui formati di file

Forum sui formati di file