Terakhir Dikemas Kini: 2026-11-04

GeoParquet vs. GeoJSON: Which GIS Format Is Best for Large Datasets?

GeoParquet vs. GeoJSON: Format GIS Mana yang Lebih Baik untuk Set Data Besar?

Jika anda pernah mencuba membuka fail GeoJSON 2 GB dalam QGIS atau memuatkan fail sempadan poligon berbilion baris ke dalam peta interaktif, anda sudah mengetahui rasa menurun akibat skrin beku dan kerosakan memori yang kehabisan.

Selama lebih daripada satu dekad, GeoJSON telah berfungsi sebagai lingua franca universal kartografi web. Ia telus, boleh dibaca manusia, dan disokong secara langsung oleh hampir setiap perpustakaan pemetaan web dan REST API di internet.

Walau bagaimanapun, aliran kerja GIS moden kelihatan sangat berbeza berbanding pada tahun 2008. Praktisi geospatial masa kini secara rutin mengimport gigabait (atau terabait) data telemetri mobiliti IoT, jejak bangunan seluruh negara, topeng segmentasi yang diperoleh daripada satelit, dan grid iklim berfrekuensi tinggi.

Apabila digunakan pada set data berskala ini, GeoJSON tidak hanya melambatkan—ia sepenuhnya menjadi titik lemah dalam seni bina data.

Masukkan GeoParquet, satu sambungan geospatial terbuka dan piawai kepada Apache Parquet yang sedang dikembangkan dalam Open Geospatial Consortium (OGC).

Dalam panduan komprehensif ini, kami membandingkan GeoParquet dan GeoJSON dari segi seni bina, kecekapan penyimpanan, kadar bacaan/penulisan, kesiapan awan, dan ergonomik pembangun untuk menjawab soalan penting: Format mana yang harus anda pilih untuk set data besar?


1. Arkitektur Struktur: Teks vs. Kolumnar Binari

Untuk memahami mengapa format-format ini berprestasi begitu berbeza pada skala besar, anda perlu melihat di sebalik tabir bagaimana setiap satu mewakili nilai koordinat dan metadata tabular.

+--------------------------------------------------------------+
| Metrik Penilaian |
| **Format Data** |
| **Representasi Geometri** |
| **Nisbah Pemampatan** |
| **Projeksi Lajur** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Penurunan Predikat Spatial** |
| **Storan Objek Awan (S3/GCS)** |
| **Kebolehbacaan Manusia** |
| **Sokongan Penyemak Imbas Web** |
| **Badan Penstandardan** |
+--------------------------------------------------------------+

GeoJSON: Berorientasi Baris, JSON Berkod Teks

GeoJSON mewakili data sebagai satu susunan objek JSON. Setiap ciri secara eksplisit mengulangi kunci atribut bersama-sama dengan satu susunan nombor titik apung yang dikodkan sebagai rentetan:

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

Kerana GeoJSON berasaskan teks:

  • Skema Berulang: Nama medan seperti \"properties\", \"type\", dan \"coordinates\" diulangi berjuta-juta kali, menyebabkan saiz fail mentah menjadi lebih besar.
  • Penukaran Rentetan-ke-Float yang Mahal: CPU anda mesti menafsirkan aksara teks (\"-\", \"9\", \"7\", \".\", \"7\"...) menjadi nombor titik apung 64-bit IEEE dwi-precision sebelum melakukan sebarang operasi spatial.
  • Keperluan Bacaan Monolitik: Pengurai JSON standard mesti memuatkan keseluruhan fail ke dalam memori untuk membina Model Objek Dokumen (DOM). Membaca satu atribut memerlukan penguraian setiap ciri.

GeoParquet: Berorientasi Kolum, Data Berkod Binari

GeoParquet dibina secara langsung di atas Apache Parquet, menyimpan jadual spatial lajur demi lajur dan bukannya baris demi baris.

Atribut seperti county disimpan dalam blok bersebelahan, membolehkan teknik pemampatan lanjutan seperti pengekodan panjang larian (RLE), pemampatan bit, dan pemampatan kamus. Data geometri diseragamkan sebagai Well-Known Binary (WKB), disertai dengan metadata JSON terbenam yang memperincikan sistem rujukan spatial (CRS), kotak sempadan, dan jenis geometri.

Kerana GeoParquet bersifat binari dan berasaskan lajur:

  • Kos Penguraian Koordinat Sifar: Geometri disimpan secara langsung dalam bentuk binari, mengelakkan penukaran rentetan kepada nombor terapung yang mahal.
  • Penurunan Projeksi: Jika aliran kerja hiliran anda hanya memerlukan lajur county dan pop_density, pembaca mengambil hanya offset bait tersebut dari cakera atau S3, sepenuhnya melangkau lajur geometri.
  • Pembahagian Kumpulan Baris: Fail Parquet membahagikan rekod ke dalam “Kumpulan Baris” yang berdiri sendiri (sering 100,000 hingga 1,000,000 baris setiap satu) lengkap dengan statistik min/maks untuk setiap lajur.

2. Perbandingan Langsung: Metrik Teras

Evaluation MetricGeoJSONGeoParquet
Data FormatPlain-text JSON (UTF-8)Binary columnar (Apache Parquet)
Geometry RepresentationNested arrays of coordinate stringsStandardized Well-Known Binary (WKB)
Compression RatioPoor (requires gzip/bzip2 to reduce)Exceptional (native Zstd, Snappy, Gzip)
Column Projection❌ No (entire record must be parsed)✅ Yes (fetch only the columns you need)
Spatial Predicate Pushdown❌ No (requires full scan)✅ Yes (using bounding box metadata)
Cloud Object Storage (S3/GCS)❌ Poor (must download full file)✅ Cloud-native (supports HTTP range requests)
Human Readability✅ Direct viewing in text editors❌ Requires CLI, GIS app, or code
Web Browser SupportNative JavaScript (JSON.parse)Requires WebAssembly (e.g., duckdb-wasm, parquet-wasm)
Standardization BodyIETF (RFC 7946)OGC (Open Geospatial Consortium standard)

3. Kecekapan Penyimpanan dan Penanda Aras Saiz Fail

Apabila skala meningkat dari ribuan kepada jutaan rekod, perbezaan penyimpanan menjadi sangat meluas secara dramatik.

Dalam penanda aras standard yang menggunakan rekod spatial terbuka dunia sebenar (seperti jejak bangunan OpenStreetMap, sempadan TIGER Banci AS, dan log AIS kapal global), GeoParquet secara rutin mencapai pengurangan penyimpanan 70% hingga 85% berbanding GeoJSON mentah, dan mengatasi .geojson.gz dengan tambahan 20% hingga 40%.

Mengapa GeoParquet begitu kecil?

  1. Dictionary Encoding: Atribut rentetan yang berulang (contoh, kod negeri, klasifikasi guna tanah) diindeks menjadi penunjuk integer kecil dan bukannya disimpan berulang kali sebagai rentetan panjang.
  2. Compact Binary Coordinates: Titik 2D dalam GeoJSON mengambil kira-kira 30 hingga 45 bait teks ASCII ([-122.4194155, 37.7749295]). Dalam WKB, pasangan koordinat yang sama memerlukan tepat 16 bait.
  3. Modern Compression Algorithms: Zstandard (Zstd) dan Snappy memampatkan tatasusunan bait kolumnar dengan jauh lebih berkesan berbanding Gzip standard yang dapat memampatkan teks berasaskan baris yang berselang-seli.

4. Prestasi Pertanyaan dan Aliran Kerja Awan Asli

Pembeza utama bagi set data besar bukan sekadar penyimpanan—ia ialah kelambatan pertanyaan dan penggunaan memori.

1. Bacaan Selektif melalui Proyeksi Kolum

Bayangkan satu set data parcel kebangsaan 15 GB yang mengandungi 60 atribut (nama pemilik, ID cukai, sejarah hak milik, kod zon, dan sempadan multipoligon yang kompleks).

  • Dalam GeoJSON: Jika anda ingin mengira nilai harta taksiran purata bagi setiap kod pos, enjin analitik anda perlu memuat turun dan mengurai semua 15 GB, termasuk berjuta‑juta simpul sempadan yang kompleks.
  • Dalam GeoParquet: Enjin analitik seperti DuckDB, Apache Sedona, Polars, atau AWS Athena membaca hanya lajur zip_code dan assessed_value. Daripada memindahkan 15 GB, enjin anda memuat turun dan mengimbas kurang daripada 80 MB.

2. Permintaan Julat HTTP pada Storan Awan

GeoParquet beroperasi dengan lancar sebagai format geospatial cloud-native.

Kerana fail Parquet menyimpan offset dalaman dan metadata dalam bahagian kaki fail mereka, perpustakaan klien boleh menghantar permintaan HTTP GET Range: bytes=... kepada storan objek awan seperti Amazon S3, Google Cloud Storage, atau Azure Blob Storage. Daripada memuat turun keseluruhan fail berbilion‑bait, klien membaca bahagian kaki, mengenal pasti offset bait yang tepat di mana rekod yang relevan berada, dan memuat turun hanya subset yang diperlukan.

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. Ekosistem Perisian & Sokongan Alat

Secara sejarah, kelebihan utama GeoJSON ialah sokongan alat yang universal. Walaupun itu masih benar untuk persekitaran pelayar, ekosistem GeoParquet telah berkembang dengan cepat:

  • Desktop GIS: Sokongan baca/tulis asli dalam QGIS 3.28+, ArcGIS Pro, dan GDAL/OGR 3.5+.
  • Enjin Analitis & Bahasa: Keupayaan baca/tulis vektor pantas merentasi Python (GeoPandas, pyarrow), R (sf), DuckDB (melalui sambungan spatial), Apache Sedona, dan Snowflake.
  • Saluran Data Besar: Integrasi asli merentasi Apache Spark, Trino, Presto, dan Databricks.
  • Peta Web Sisi Klien: Perpustakaan WebAssembly ringan (seperti parquet-wasm dan duckdb-wasm) kini membolehkan pelayar web menanya fail GeoParquet secara langsung pada peranti klien tanpa pelayan middleware GIS khusus.

6. Matriks Keputusan Praktikal: Bila Menggunakan Yang Mana?

                                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

Pilih GeoJSON Jika:

  • Set data anda berada di bawah 50 MB hingga 100 MB.
  • Anda menghantar respons muatan ringan dari API REST kepada klien frontend.
  • Anda sedang membina peta web ringan menggunakan Leaflet, MapLibre, atau Mapbox GL JS tanpa lapisan terjemahan antara.
  • Anda memerlukan penyuntingan atau pemeriksaan manual yang cepat dalam penyunting kod atau teks standard.

Pilih GeoParquet Jika:

  • Set data anda melebihi 100 MB, atau mengandungi ratusan ribu ciri spatial yang kompleks.
  • Anda menyimpan aset vektor dalam storan objek awan (S3, GCS, MinIO, Azure Blob).
  • Anda menjalankan analitik SQL spatial, kejuruteraan ciri, atau paip pembelajaran mesin menggunakan Python, DuckDB, Spark, atau Databricks.
  • Anda ingin mengurangkan kos penyimpanan, mengelakkan yuran egress rangkaian, dan menghapuskan kerosakan memori.

7. Contoh Migrasi: Menukar GeoJSON kepada GeoParquet

Menukar aset spatial sedia ada kepada GeoParquet hanya memerlukan beberapa baris kod.

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

Menggunakan GDAL / OGR (CLI)

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

Menggunakan 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. Ringkasan: Keputusan Mengenai Set Data Besar

Untuk set data kecil dan titik akhir web langsung, GeoJSON tetap menjadi format utiliti yang boleh dipercayai dan tanpa kerumitan.

Namun, untuk set data besar, GeoParquet secara objektif lebih unggul dalam setiap kategori operasi. Ia memberikan jejak fail yang lebih kecil, beban penyimpanan yang jauh lebih rendah, bacaan spatial hampir serta-merta, dan integrasi asli dengan gudang data awan moden.

Jika paip geospatial anda mengeluh di bawah beban fail GeoJSON yang terlalu besar, beralih kepada GeoParquet adalah salah satu peningkatan infrastruktur yang paling berkesan yang boleh anda lakukan.


Soalan Lazim (FAQ)

Q1. Adakah GeoParquet merupakan standard GIS yang diiktiraf secara rasmi? Ya, GeoParquet adalah standard terbuka rasmi yang diselenggara di bawah panduan Open Geospatial Consortium (OGC).

Q2. Bolehkah saya memaparkan fail GeoParquet secara langsung dalam perpustakaan pemetaan web seperti Leaflet atau Mapbox GL JS? Walaupun tidak diparse secara asli seperti GeoJSON, anda boleh memaparkan GeoParquet dalam pelayar menggunakan pakej WebAssembly seperti parquet-wasm atau dengan menukar fail kepada Vector Tiles (PMTiles/MVT) semasa penyerapan.

Q3. Adakah GeoParquet menyokong pelbagai sistem rujukan koordinat (CRS)? Ya, tidak seperti GeoJSON (yang secara ketat terhad kepada WGS 84 / EPSG:4326 mengikut RFC 7946), GeoParquet membenarkan definisi CRS tersuai secara langsung dalam metadata fail yang terbenam.

Q4. Bagaimana GeoParquet dibandingkan dengan FlatGeobuf untuk set data spatial yang besar? FlatGeobuf dioptimumkan untuk penstriman ciri spatial secara langsung ke peta web interaktif menggunakan indeks spatial R-Tree, manakala GeoParquet direka untuk analitik kolumnar berprestasi tinggi, pemampatan, dan penyimpanan data tasik data yang besar.

Q5. Bolehkah saya membuka fail GeoParquet dalam perisian GIS desktop seperti QGIS? Ya, versi moden QGIS (versi 3.28 dan ke atas) menyokong seret, lepas, melihat, dan menggayakan fail GeoParquet tanpa memerlukan plugin pihak ketiga.

Lihat Juga

Format Fail GIS di FileFormat.com

5 Format Fail GIS Teratas untuk Google Maps

Berita Format Fail

Forum Format Fail