最終更新: 2026-11-04

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

GeoParquet vs. GeoJSON: 大規模データセットに最適なGISフォーマットはどれですか？

QGIS で 2 GB の GeoJSON ファイルを開こうとしたり、何百万行ものポリゴン境界ファイルをインタラクティブマップに読み込んだことがあるなら、画面がフリーズし、メモリ不足でクラッシュするという沈むような感覚をすでに知っているでしょう。

10 年以上にわたり、GeoJSON はウェブ地図作成の普遍的な共通語として機能してきました。透明性が高く、人間が読め、インターネット上のほぼすべてのウェブマッピングライブラリや REST API で標準的にサポートされています。

しかし、現代の GIS ワークフローは 2008 年当時とは根本的に異なります。今日の地理空間の実務者は、ギガバイト（またはテラバイト）規模の IoT モビリティテレメトリ、全国規模の建物輪郭、衛星由来のセグメンテーションマスク、高頻度の気候グリッドなどを日常的に取り込んでいます。

この規模のデータセットに適用すると、GeoJSON は単に遅くなるだけでなく、データアーキテクチャ全体を完全にボトルネックします。

ここで登場するのが GeoParquet です。これは、Open Geospatial Consortium (OGC) 内でインキュベートされている、Apache Parquet 用のオープンで標準化された地理空間拡張です。

この包括的なガイドでは、アーキテクチャ、ストレージ効率、読み書きスループット、クラウド対応、開発者エルゴノミクスの観点から GeoParquet と GeoJSON を比較し、重要な質問に答えます：大規模データセットにはどのフォーマットを選ぶべきか？

1. 構造アーキテクチャ：テキスト vs. バイナリ カラム指向

これらのフォーマットがスケール時になぜこれほど異なる性能を示すのかを理解するには、各フォーマットが座標値と表形式メタデータをどのように表現しているかを内部で確認する必要があります。

+--------------------------------------------------------------+
| 評価指標 |
| **データ形式** |
| **ジオメトリ表現** |
| **圧縮率** |
| **列投影** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **空間述語プッシュダウン** |
| **クラウドオブジェクトストレージ（S3/GCS）** |
| **人間可読性** |
| **Webブラウザのサポート** |
| **標準化団体** |
+--------------------------------------------------------------+

GeoJSON：行指向、テキストエンコードされた JSON

GeoJSON はデータを JSON オブジェクトの配列として表現します。各フィーチャは属性キーを明示的に繰り返し、文字列としてエンコードされた浮動小数点数の配列と共に保持します：

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

GeoJSON がテキストベースであるため：

  • 繰り返しスキーマ: "properties"、"type"、"coordinates" のようなフィールド名が何百万回も繰り返され、生のファイルサイズが膨らみます。
  • 高コストな文字列から浮動小数点への変換: CPU は空間演算を行う前に、テキスト文字（"-", "9", "7", ".", "7"...）を 64 ビット IEEE ダブル精度浮動小数点数に解析しなければなりません。
  • モノリシックな読み取り要件: 標準的な JSON パーサは、Document Object Model（DOM）を構築するためにファイル全体をメモリに取り込む必要があります。1 つの属性を読むだけでも、すべてのフィーチャを解析しなければなりません。

GeoParquet：列指向、バイナリエンコードされたデータ

GeoParquetはApache Parquetの上に直接構築され、空間テーブルを行単位ではなく列単位で保存します。

county のような属性は連続したブロックに格納され、ランレングスエンコーディング（RLE）、ビットパッキング、辞書圧縮などの高度な圧縮手法が可能です。ジオメトリデータはWell-Known Binary (WKB) として標準化され、空間参照系（CRS）、バウンディングボックス、ジオメトリタイプを詳細に記述した埋め込みJSONメタデータが付随します。

GeoParquetはバイナリかつ列指向であるため：

  • Zero Coordinate Parsing Cost: ジオメトリはバイナリ形式で直接保存され、コストのかかる文字列から浮動小数点への変換を回避します。
  • Projection Pushdown: 下流のワークフローが county と pop_density 列だけを必要とする場合、リーダーはディスクまたはS3からそのバイトオフセットだけを取得し、ジオメトリ列を完全にスキップします。
  • Row-Group Partitioning: Parquetファイルはレコードを自己完結型の"Row Groups"（通常は10万から100万行）に分割し、各列の最小/最大統計情報を含みます。

2. ヘッド・ツー・ヘッド比較：コア指標

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. ストレージ効率とファイルサイズベンチマーク

数千件から数百万件へスケールする際、ストレージの格差は劇的に拡大します。

実際のオープン空間データ（OpenStreetMap の建物輪郭、米国国勢調査 TIGER 境界、世界の船舶 AIS ログなど）を使用した標準ベンチマークでは、GeoParquet は生の GeoJSON と比較して 70% から 85% のストレージ削減 を常に実現し、さらに .geojson.gz より 20% から 40% 余分に優れています。

なぜ GeoParquet はこれほど小さいのか？

  1. Dictionary Encoding: 繰り返し使用される文字列属性（例：州コード、土地利用分類）は、長い文字列として繰り返し保存されるのではなく、小さな整数ポインタにインデックス化されます。
  2. Compact Binary Coordinates: GeoJSON の 2 次元ポイントは約 30〜45 バイトの ASCII テキスト（[-122.4194155, 37.7749295]）を使用します。WKB では、同じ座標ペアは正確に 16 バイトで表現されます。
  3. Modern Compression Algorithms: Zstandard（Zstd）と Snappy は、標準的な Gzip がインターリーブされた行ベースのテキストを圧縮するよりも、列指向バイト配列をはるかに効果的に圧縮します。

4. クエリパフォーマンスとクラウドネイティブワークフロー

大規模データセットにおける最大の差別化要因は単なるストレージだけでなく、クエリ遅延とメモリ使用率 です。

1. カラム投影による選択的読み取り

15 GB の全国 parcel データセットがあり、60 の属性（所有者名、税務 ID、権利履歴、ゾーニングコード、複雑なマルチポリゴン境界）を含んでいると想像してください。

  • GeoJSON では: ZIP コードごとの平均評価額を計算したい場合、分析エンジンは 15 GB 全体をダウンロードして解析する必要があります。これには何百万もの複雑な境界頂点が含まれます。
  • GeoParquet では: DuckDB、Apache Sedona、Polars、または AWS Athena などの分析エンジンは zip_code と assessed_value 列だけを 読み取ります。15 GB を転送する代わりに、エンジンは 80 MB 未満をダウンロードしてスキャンします。

2. クラウドストレージでの HTTP Range リクエスト

GeoParquet は クラウドネイティブな地理空間フォーマット としてシームレスに動作します。

Parquet ファイルは内部オフセットとメタデータをファイルフッターに格納するため、クライアントライブラリは Amazon S3、Google Cloud Storage、Azure Blob Storage などのクラウドオブジェクトストアに対して HTTP GET Range: bytes=... リクエストを発行できます。マルチギガバイトのファイル全体をダウンロードする代わりに、クライアントはフッターを読み取り、関連レコードが存在する正確なバイトオフセットを特定し、必要なサブセットだけをダウンロードします。

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. ソフトウェアエコシステムとツールサポート

歴史的に、GeoJSON の主な利点は汎用ツールのサポートでした。ブラウザ環境では依然として当てはまりますが、GeoParquet のエコシステムは急速に成熟しています：

  • Desktop GIS: QGIS 3.28+、ArcGIS Pro、GDAL/OGR 3.5+ におけるネイティブな読み書きサポート。
  • Analytical Engines & Languages: Python（GeoPandas、pyarrow）、R（sf）、DuckDB（空間拡張経由）、Apache Sedona、Snowflake にまたがる高速ベクトル化読み書き機能。
  • Big Data Pipelines: Apache Spark、Trino、Presto、Databricks 全体でのネイティブ統合。
  • Client-Side Web Maps: parquet-wasm や duckdb-wasm などの軽量 WebAssembly ライブラリにより、専用の GIS ミドルウェアサーバーなしで、ウェブブラウザがクライアントデバイス上で直接 GeoParquet ファイルをクエリできるようになりました。

6. 実用的な意思決定マトリックス：どれをいつ使うべきか？

                                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

次の場合は GeoJSON を選択：

  • データセットが 50 MB から 100 MB 未満です。
  • REST API からフロントエンドクライアントへ軽量なペイロードレスポンスを返しています。
  • Leaflet、MapLibre、または Mapbox GL JS を使用して、中間の変換レイヤーなしで軽量なウェブマップを構築しています。
  • 標準的なコードエディタまたはテキストエディタで迅速な手動編集や検査が必要です。

次の場合は GeoParquet を選択：

  • データセットが100 MBを超える、または数十万もの複雑な空間フィーチャを含んでいます。
  • ベクトル資産をクラウドオブジェクトストレージ（S3、GCS、MinIO、Azure Blob）に保存しています。
  • Python、DuckDB、Spark、Databricks を使用して空間 SQL 分析、特徴量エンジニアリング、または機械学習パイプラインを実行しています。
  • ストレージコストを削減し、ネットワークアウトバウンド料金を回避し、メモリクラッシュを防止したいです。

7. 移行例：GeoJSON から GeoParquet への変換

既存の空間資産を GeoParquet に変換するには、数行のコードだけで済みます。

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

GDAL / OGR を使用 (CLI)

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

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. 要約: 大規模データセットに関する結論

小規模データセットや直接的なウェブエンドポイントの場合、GeoJSON は信頼性が高く、手間のかからないユーティリティ形式のままです。

しかし、大規模データセットに対しては、GeoParquet がすべての運用カテゴリで客観的に優れています。ファイルサイズが小さく、ストレージオーバーヘッドが大幅に低減され、ほぼ瞬時の空間読み取りが可能で、最新のクラウドデータウェアハウスとネイティブに統合されます。

ジオスペーシャルパイプラインがサイズオーバーしたGeoJSONファイルの重さでうんざりしているなら、GeoParquetへの切り替えは最も効果的なインフラストラクチャのアップグレードの一つです。

よくある質問 (FAQ)

Q1. GeoParquetは公式に認められたGIS標準ですか？ はい、GeoParquetはOpen Geospatial Consortium（OGC）の指導の下で維持されている公式のオープン標準です。

Q2. LeafletやMapbox GL JSなどのウェブマッピングライブラリでGeoParquetファイルを直接レンダリングできますか？ GeoJSONのようにネイティブに解析されるわけではありませんが、parquet-wasmなどのWebAssemblyパッケージを使用したり、取り込み時にファイルをベクトルタイル（PMTiles/MVT）に変換することで、ブラウザでGeoParquetをレンダリングできます。

Q3. GeoParquetは複数の座標参照系（CRS）をサポートしていますか？ はい、GeoJSONがRFC 7946でWGS 84 / EPSG:4326に厳密に限定されているのとは異なり、GeoParquetは埋め込みファイルメタデータ内にカスタムCRS定義を直接許可します。

Q4. 大規模な空間データセットにおいて、GeoParquetはFlatGeobufとどのように比較されますか？ FlatGeobufはR-Tree空間インデックスを使用して、インタラクティブなウェブマップへ空間フィーチャを直接ストリーミングするよう最適化されているのに対し、GeoParquetは高性能なカラム指向分析、圧縮、そして大規模データレイクウェアハウジング向けに設計されています。

Q5. QGISなどのデスクトップGISソフトウェアでGeoParquetファイルを開くことはできますか？ はい、QGISの最新バージョン（3.28以降）は、サードパーティプラグインを必要とせずにGeoParquetファイルのドラッグ＆ドロップ、表示、スタイリングをサポートしています。

関連項目

FileFormat.comのGISファイル形式

Google Maps向けトップ5 GISファイル形式

ファイル形式ニュース

ファイル形式フォーラム