GeoParquet vs. GeoJSON - Desempenho, tamanho de arquivo e GIS nativo da nuvem comparados

Última atualização: 2026-11-04

GeoParquet vs. GeoJSON: Qual formato GIS é melhor para grandes conjuntos de dados?

Se você já tentou abrir um arquivo GeoJSON de 2 GB no QGIS ou carregar um arquivo de limites de polígonos com milhões de linhas em um mapa interativo, já conhece a sensação de tela congelada e um travamento por falta de memória.

Por mais de uma década, GeoJSON tem sido a lingua franca universal da cartografia web. É transparente, legível por humanos e suportado prontamente por quase todas as bibliotecas de mapeamento web e APIs REST na internet.

No entanto, os fluxos de trabalho modernos de GIS são radicalmente diferentes dos de 2008. Os profissionais de geoespacial de hoje ingerem rotineiramente gigabytes (ou terabytes) de telemetria de mobilidade IoT, contornos de edifícios em todo o país, máscaras de segmentação derivadas de satélite e grades climáticas de alta frequência.

Quando aplicados a conjuntos de dados nessa escala, o GeoJSON não apenas desacelera — ele cria um gargalo completo nas arquiteturas de dados.

Apresentamos GeoParquet, uma extensão geoespacial aberta e padronizada para Apache Parquet, incubada dentro do Open Geospatial Consortium (OGC).

Neste guia abrangente, comparamos GeoParquet e GeoJSON em termos de arquitetura, eficiência de armazenamento, taxa de leitura/gravação, prontidão para a nuvem e ergonomia para desenvolvedores, para responder a uma pergunta crítica: Qual formato você deve escolher para grandes conjuntos de dados?

1. Arquitetura Estrutural: Texto vs. Colunar Binário

Para entender por que esses formatos apresentam desempenho tão diferente em escala, você precisa olhar nos bastidores de como cada um representa valores de coordenadas e metadados tabulares.

+--------------------------------------------------------------+
| Métrica de Avaliação |
| **Formato de Dados** |
| **Representação Geométrica** |
| **Taxa de Compressão** |
| **Projeção de Colunas** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Pushdown de Predicado Espacial** |
| **Armazenamento de Objetos na Nuvem (S3/GCS)** |
| **Legibilidade Humana** |
| **Suporte a Navegadores Web** |
| **Entidade de Padronização** |
+--------------------------------------------------------------+

GeoJSON: Orientado a Linhas, JSON Codificado em Texto

GeoJSON representa os dados como um array de objetos JSON. Cada recurso repete explicitamente as chaves de atributos ao lado de um array de números de ponto flutuante codificados como strings:

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

Porque o GeoJSON é baseado em texto:

• Esquemas Repetitivos: Nomes de campos como "properties", "type" e "coordinates" são repetidos milhões de vezes, aumentando o tamanho bruto do arquivo.
• Conversão Custosa de String para Float: Sua CPU deve analisar caracteres de texto ("-", "9", "7", ".", "7"...) em floats de precisão dupla IEEE de 64 bits antes de executar qualquer operação espacial.
• Requisitos de Leitura Monolítica: Analisadores JSON padrão precisam ingerir o arquivo inteiro na memória para construir o Modelo de Objeto de Documento (DOM). Ler um atributo requer analisar cada recurso individualmente.

GeoParquet: Orientado a Colunas, Dados Codificados em Binário

GeoParquet é construído diretamente sobre Apache Parquet, armazenando tabelas espaciais coluna por coluna em vez de linha por linha.

Atributos como county são armazenados em blocos contíguos, permitindo técnicas avançadas de compressão como codificação run-length (RLE), empacotamento de bits e compressão por dicionário. Dados de geometria são padronizados como Well-Known Binary (WKB), acompanhados por metadados JSON incorporados que detalham sistemas de referência espacial (CRS), caixas delimitadoras e tipos de geometria.

Porque o GeoParquet é binário e columnar:

• Custo Zero de Análise de Coordenadas: Geometrias são armazenadas diretamente em forma binária, contornando conversões caras de string para float.
• Pushdown de Projeção: Se seu fluxo de trabalho downstream precisar apenas das colunas county e pop_density, o leitor busca apenas esses deslocamentos de bytes do disco ou S3, ignorando completamente a coluna de geometria.
• Particionamento por Row-Group: Arquivos Parquet dividem registros em “Row Groups” autônomos (geralmente de 100.000 a 1.000.000 de linhas cada) completos com estatísticas de min/max para cada coluna.

2. Comparação Lado a Lado: Métricas Principais

3. Eficiência de Armazenamento e Métricas de Tamanho de Arquivo

Ao escalar de milhares para milhões de registros, as disparidades de armazenamento aumentam drasticamente.

Em benchmarks padrão usando registros espaciais abertos do mundo real (como contornos de edifícios do OpenStreetMap, limites TIGER do Censo dos EUA e logs globais de AIS de navios), o GeoParquet rotineiramente alcança reduções de armazenamento de 70% a 85% em comparação ao GeoJSON bruto, e supera .geojson.gz em 20% a 40% adicionais.

Por que o GeoParquet é muito menor?

1. Codificação por Dicionário: Atributos de string repetidos (por exemplo, códigos de estado, classificações de uso da terra) são indexados em pequenos ponteiros inteiros em vez de serem armazenados repetidamente como strings longas.
2. Coordenadas Binárias Compactas: Um ponto 2D no GeoJSON ocupa cerca de 30 a 45 bytes de texto ASCII ([-122.4194155, 37.7749295]). No WKB, esse mesmo par de coordenadas requer exatamente 16 bytes.
3. Algoritmos de Compressão Modernos: Zstandard (Zstd) e Snappy comprimem arrays de bytes colunar muito mais efetivamente do que o Gzip padrão pode comprimir texto intercalado baseado em linhas.

4. Desempenho de Consulta e Fluxos de Trabalho Nativos na Nuvem

O maior diferencial para grandes conjuntos de dados não é apenas o armazenamento — é latência de consulta e utilização de memória.

1. Leituras Seletivas via Projeção de Colunas

Imagine um conjunto de dados nacional de parcelas de 15 GB contendo 60 atributos (nomes dos proprietários, IDs fiscais, histórico de escrituras, códigos de zoneamento e limites complexos de multipolígonos).

• Em GeoJSON: Se você quiser calcular o valor médio avaliado da propriedade por código postal, seu motor analítico precisa baixar e analisar todos os 15 GB, incluindo milhões de vértices de limites complexos.
• Em GeoParquet: Motores analíticos como DuckDB, Apache Sedona, Polars ou AWS Athena leem apenas as colunas zip_code e assessed_value. Em vez de transferir 15 GB, seu motor baixa e escaneia menos de 80 MB.

2. Solicitações de Intervalo HTTP em Armazenamento em Nuvem

GeoParquet funciona perfeitamente como um formato geoespacial nativo da nuvem.

Como os arquivos Parquet armazenam deslocamentos internos e metadados em seu rodapé, as bibliotecas cliente podem emitir solicitações HTTP GET Range: bytes=... para armazenamentos de objetos na nuvem como Amazon S3, Google Cloud Storage ou Azure Blob Storage. Em vez de baixar um arquivo de vários gigabytes inteiro, o cliente lê o rodapé, identifica os deslocamentos de bytes exatos onde os registros relevantes estão e baixa apenas os subconjuntos necessários.

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. Ecossistema de Software e Suporte a Ferramentas

Historicamente, a principal vantagem do GeoJSON era o suporte universal de ferramentas. Embora isso ainda seja verdade para ambientes de navegador, o ecossistema do GeoParquet amadureceu rapidamente:

• Desktop GIS: Suporte nativo de leitura/gravação em QGIS 3.28+, ArcGIS Pro e GDAL/OGR 3.5+.
• Mecanismos Analíticos e Linguagens: Capacidades rápidas de leitura/gravação vetorizada em Python (GeoPandas, pyarrow), R (sf), DuckDB (via a extensão espacial), Apache Sedona e Snowflake.
• Big Data Pipelines: Integração nativa com Apache Spark, Trino, Presto e Databricks.
• Mapas Web do Lado do Cliente: Bibliotecas leves de WebAssembly (como parquet-wasm e duckdb-wasm) agora permitem que navegadores web consultem arquivos GeoParquet diretamente nos dispositivos do cliente sem um servidor middleware GIS dedicado.

6. Matriz de Decisão Prática: Quando Usar Cada Uma?

                                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

Escolha GeoJSON Se:

• Seu conjunto de dados tem entre 50 MB e 100 MB.
• Você está retornando respostas de payload leves de uma API REST para clientes front-end.
• Você está construindo mapas web leves usando Leaflet, MapLibre ou Mapbox GL JS sem camadas de tradução intermediárias.
• Você precisa de edição ou inspeção manual rápida em um editor de código ou texto padrão.

Escolha GeoParquet Se:

• Seu conjunto de dados excede 100 MB ou contém centenas de milhares de recursos espaciais complexos.
• Você está armazenando ativos vetoriais em armazenamento de objetos na nuvem (S3, GCS, MinIO, Azure Blob).
• Você executa análises espaciais em SQL, engenharia de recursos ou pipelines de aprendizado de máquina usando Python, DuckDB, Spark ou Databricks.
• Você deseja reduzir custos de armazenamento, evitar taxas de saída de rede e eliminar falhas de memória.

7. Exemplo de Migração: Convertendo GeoJSON para GeoParquet

Converter ativos espaciais existentes para GeoParquet leva apenas algumas linhas de código.

Usando 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")

Usando GDAL / OGR (CLI)

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

Usando 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. Resumo: O Veredicto sobre Grandes Conjuntos de Dados

Para conjuntos de dados pequenos e endpoints web diretos, o GeoJSON continua sendo um formato utilitário confiável e sem complicações.

No entanto, para grandes conjuntos de dados, o GeoParquet é objetivamente superior em todas as categorias operacionais. Ele oferece footprints de arquivos menores, sobrecarga de armazenamento significativamente menor, leituras espaciais quase instantâneas e integração nativa com modernos data warehouses em nuvem.

Se os seus pipelines geoespaciais estão gemendo sob o peso de arquivos GeoJSON superdimensionados, mudar para GeoParquet é uma das atualizações de infraestrutura mais eficazes que você pode fazer.

Perguntas Frequentes (FAQ)

Q1. O GeoParquet é um padrão GIS oficialmente reconhecido? Sim, o GeoParquet é um padrão aberto oficial mantido sob a orientação do Open Geospatial Consortium (OGC).

Q2. Posso renderizar um arquivo GeoParquet diretamente em bibliotecas de mapeamento web como Leaflet ou Mapbox GL JS? Embora não seja analisado nativamente como o GeoJSON, você pode renderizar GeoParquet em navegadores usando pacotes WebAssembly como parquet-wasm ou convertendo arquivos para Vector Tiles (PMTiles/MVT) na ingestão.

Q3. O GeoParquet suporta múltiplos sistemas de referência de coordenadas (CRS)? Sim, ao contrário do GeoJSON (que é estritamente restrito ao WGS 84 / EPSG:4326 pelo RFC 7946), o GeoParquet permite definições personalizadas de CRS diretamente dentro dos metadados incorporados do arquivo.

Q4. Como o GeoParquet se compara ao FlatGeobuf para grandes conjuntos de dados espaciais? FlatGeobuf é otimizado para transmissão de recursos espaciais diretamente para mapas web interativos usando indexação espacial R-Tree, enquanto o GeoParquet foi projetado para análises colunar de alto desempenho, compressão e armazenamento massivo em data lakes.

Q5. Posso abrir arquivos GeoParquet em softwares GIS de desktop como o QGIS? Sim, versões modernas do QGIS (versão 3.28 e superiores) suportam arrastar, soltar, visualizar e estilizar arquivos GeoParquet sem a necessidade de plugins de terceiros.

Veja também

Formatos de Arquivo GIS em FileFormat.com

Os 5 Principais Formatos de Arquivo GIS para Google Maps

Notícias de Formatos de Arquivo

Fóruns de Formatos de Arquivo