Son Güncelleme: 2026-11-04

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

GeoParquet vs. GeoJSON: Büyük Veri Setleri İçin Hangi GIS Formatı Daha İyi?

Eğer bir zamanlar QGIS’te 2 GB’lık bir GeoJSON dosyasını açmaya ya da milyonlarca satırlık bir çokgen sınır dosyasını etkileşimli bir haritaya yüklemeye çalıştıysanız, donmuş bir ekran ve bellek yetersizliği hatasının verdiği o sıkıntıyı zaten biliyorsunuz.

On yıldan fazla bir süredir, GeoJSON web kartografinin evrensel ortak dili olarak hizmet vermektedir. Şeffaf, insan tarafından okunabilir ve internet üzerindeki hemen hemen tüm web haritalama kütüphanesi ve REST API tarafından kutudan çıkar çıkmaz desteklenmektedir.

Bununla birlikte, modern GIS iş akışları 2008’dekinden kökten farklı görünmektedir. Günümüz coğrafi veri uzmanları rutin olarak gigabayt (veya terabayt) seviyesinde IoT hareketlilik telemetrisi, ulusal çapta bina ayak izleri, uydu kaynaklı segmentasyon maskeleri ve yüksek frekanslı iklim ızgaralarını alırlar.

Bu ölçekteki veri setlerine uygulandığında, GeoJSON sadece yavaşlamaz—veri mimarilerini tamamen darboğaza sokar.

GeoParquet‘i tanıyın, Open Geospatial Consortium (OGC) içinde gelişmekte olan Apache Parquet’e açık, standartlaştırılmış bir coğrafi uzantı.

Bu kapsamlı rehberde, mimari, depolama verimliliği, okuma/yazma verimliliği, bulut hazırlığı ve geliştirici ergonomisi açısından GeoParquet ve GeoJSON’ı karşılaştırarak kritik bir soruya yanıt veriyoruz: Büyük veri setleri için hangi formatı seçmelisiniz?


1. Yapısal Mimari: Metin vs. İkili Sütunlu

Bu formatların ölçeklendikçe neden bu kadar farklı performans gösterdiğini anlamak için, her birinin koordinat değerlerini ve tablo meta verilerini nasıl temsil ettiğine derinlemesine bakmanız gerekir.

+--------------------------------------------------------------+
| Değerlendirme Ölçütü |
| **Veri Formatı** |
| **Geometri Temsili** |
| **Sıkıştırma Oranı** |
| **Sütun Projeksiyonu** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Uzamsal Koşul İtme** |
| **Bulut Nesne Depolama (S3/GCS)** |
| **İnsan Okunabilirliği** |
| **Web Tarayıcı Desteği** |
| **Standardizasyon Kurumu** |
+--------------------------------------------------------------+

GeoJSON: Satır Yönelimli, Metin Kodlu JSON

GeoJSON, verileri bir JSON nesneleri dizisi olarak temsil eder. Her bir özellik, dizeyle kodlanmış kayan nokta sayılarının bir dizisiyle birlikte öznitelik anahtarlarını açıkça tekrar eder:

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

GeoJSON metin tabanlı olduğu için:

  • Tekrarlayan Şemalar: "properties", "type" ve "coordinates" gibi alan adları milyonlarca kez tekrarlanarak ham dosya boyutunu şişirir.
  • Maliyetli Dize‑İle‑Float Dönüşümü: CPU’nuz, herhangi bir uzamsal işlem yapmadan önce metin karakterlerini ("-", "9", "7", ".", "7"...) 64‑bit IEEE çift hassasiyetli float’lara ayrıştırmak zorundadır.
  • Tek Parçalı Okuma Gereksinimleri: Standart JSON ayrıştırıcıları, Belge Nesne Modeli (DOM) oluşturmak için tüm dosyayı belleğe yüklemek zorundadır. Tek bir özniteliği okumak, her bir özelliği ayrıştırmayı gerektirir.

GeoParquet: Sütun Yönelimli, İkili Kodlu Veri

GeoParquet doğrudan Apache Parquet üzerine inşa edilir ve mekansal tabloları satır satır yerine sütun sütun depolar.

county gibi öznitelikler ardışık bloklarda depolanır, bu da koşu uzunluğu kodlaması (RLE), bit paketleme ve sözlük sıkıştırması gibi gelişmiş sıkıştırma tekniklerine olanak tanır. Geometri verileri Well-Known Binary (WKB) olarak standartlaştırılır ve gömülü JSON meta verileriyle birlikte mekânsal referans sistemlerini (CRS), sınırlama kutularını ve geometri tiplerini detaylandırır.

GeoParquet ikili ve sütunlu olduğu için:

  • Sıfır Koordinat Ayrıştırma Maliyeti: Geometriler doğrudan ikili biçimde depolanır, maliyetli string‑to‑float dönüşümlerini atlar.
  • Projeksiyon İtme: Eğer aşağı akış iş akışınız yalnızca county ve pop_density sütunlarına ihtiyaç duyuyorsa, okuyucu diskte veya S3’teki sadece bu bayt ofsetlerini alır ve geometri sütununu tamamen atlar.
  • Satır-Grup Bölümlendirme: Parquet dosyaları kayıtları kendi içinde “Row Groups” (genellikle her biri 100.000 ila 1.000.000 satır) olarak bölerek, her sütun için min/maks istatistikleriyle birlikte sunar.

2. Yüz Yüze Karşılaştırma: Temel Ölçütler

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. Depolama Verimliliği ve Dosya Boyutu Kıyaslamaları

Binlerce kayıttan milyonlarca kayda ölçeklendirirken, depolama farkları dramatik bir şekilde artar.

Gerçek dünya açık mekansal kayıtları (OpenStreetMap bina sınırları, ABD Nüfus Sayımı TIGER sınırları ve küresel gemi AIS günlükleri gibi) kullanan standart benchmarklarda, GeoParquet, ham GeoJSON’a kıyasla %70 ila %85 depolama tasarrufu sağlar ve .geojson.gz‘yi ek olarak %20 ila %40 daha geride bırakır.

GeoParquet neden bu kadar küçük?

  1. Dictionary Encoding: Tekrarlanan dize öznitelikleri (ör. eyalet kodları, arazi kullanım sınıflandırmaları) uzun dizeler olarak tekrar tekrar depolanmak yerine küçük tamsayı işaretçilerine indekslenir.
  2. Compact Binary Coordinates: GeoJSON’da bir 2B nokta yaklaşık 30 ila 45 bayt ASCII metni ([-122.4194155, 37.7749295]) alır. WKB’de aynı koordinat çifti tam olarak 16 bayt gerektirir.
  3. Modern Compression Algorithms: Zstandard (Zstd) ve Snappy, sütun temelli bayt dizilerini, standart Gzip’in iç içe satır temelli metni sıkıştırmasından çok daha etkili bir şekilde sıkıştırır.

4. Sorgu Performansı ve Bulut Yerel İş Akışları

Büyük veri setleri için en büyük ayırt edici özellik sadece depolama değil—sorgu gecikmesi ve bellek kullanımıdır.

1. Sütun Projeksiyonu ile Seçici Okumalar

15 GB’lik bir ulusal parsel veri kümesini hayal edin; içinde 60 özellik (sahip adı, vergi kimlik numaraları, tapu geçmişi, imar kodları ve karmaşık çokgen sınırları) bulunuyor.

  • GeoJSON’da: Ortalama tahmini mülk değerini posta koduna göre hesaplamak istiyorsanız, analiz motorunuz tüm 15 GB’ı indirmek ve ayrıştırmak zorunda kalır, milyonlarca karmaşık sınır köşesi dahil.
  • GeoParquet’ta: DuckDB, Apache Sedona, Polars veya AWS Athena gibi analiz motorları sadece zip_code ve assessed_value sütunlarını okur. 15 GB transfer etmek yerine, motorunuz 80 MB’den azını indirir ve tarar.

2. Bulut Depolamada HTTP Aralık İstekleri

GeoParquet, bulut‑yerel coğrafi veri formatı olarak sorunsuz çalışır.

Parquet dosyaları iç offset’leri ve meta verileri dosya altbilgisinde sakladığı için, istemci kütüphaneleri Amazon S3, Google Cloud Storage veya Azure Blob Storage gibi bulut nesne depolarına HTTP GET Range: bytes=... istekleri gönderebilir. Tüm çok gigabaytlık dosyayı indirmek yerine, istemci altbilgiyi okur, ilgili kayıtların bulunduğu tam byte offset’lerini belirler ve yalnızca gerekli alt kümeleri indirir.

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. Yazılım Ekosistemi ve Araç Desteği

Tarihsel olarak, GeoJSON’un temel avantajı evrensel araç desteği idi. Bu durum tarayıcı ortamları için hâlâ geçerli olsa da, GeoParquet ekosistemi hızla olgunlaştı:

  • Desktop GIS: QGIS 3.28+, ArcGIS Pro ve GDAL/OGR 3.5+ içinde yerel okuma/yazma desteği.
  • Analytical Engines & Languages: Python (GeoPandas, pyarrow), R (sf), DuckDB (spatial uzantısı aracılığıyla), Apache Sedona ve Snowflake üzerinde hızlı vektörleştirilmiş okuma/yazma yetenekleri.
  • Big Data Pipelines: Apache Spark, Trino, Presto ve Databricks arasında yerel entegrasyon.
  • Client-Side Web Maps: Hafif WebAssembly kütüphaneleri (örneğin parquet-wasm ve duckdb-wasm) artık web tarayıcılarının, ayrı bir GIS ara katman sunucusu olmadan, istemci cihazlarında doğrudan GeoParquet dosyalarını sorgulamasına izin veriyor.

6. Pratik Karar Matrisi: Hangi Durumda Hangi Kullanılır?

                                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’i Şu Durumda Seçin:

  • Veri kümeniz 50 MB ile 100 MB arasında.
  • REST API’den ön uç istemcilere hafif yük yanıtları döndürüyorsunuz.
  • Leaflet, MapLibre veya Mapbox GL JS kullanarak ara çeviri katmanları olmadan hafif web haritaları oluşturuyorsunuz.
  • Standart bir kod veya metin düzenleyicisinde hızlı manuel düzenleme veya inceleme yapmanız gerekiyor.

GeoParquet’i Şu Durumda Seçin:

  • Veri kümeniz 100 MB’ı aşıyor ya da yüz binlerce karmaşık uzamsal özelliğe sahip.
  • Vektör varlıklarını bulut nesne depolama (S3, GCS, MinIO, Azure Blob) içinde depoluyorsunuz.
  • Python, DuckDB, Spark veya Databricks kullanarak uzamsal SQL analizleri, özellik mühendisliği veya makine öğrenimi boru hatları çalıştırıyorsunuz.
  • Depolama maliyetlerini azaltmak, ağ çıkış ücretlerinden kaçınmak ve bellek çöküşlerini ortadan kaldırmak istiyorsunuz.

7. Göç Örneği: GeoJSON’dan GeoParquet’e Dönüştürme

Mevcut uzamsal varlıkları GeoParquet’e dönüştürmek sadece birkaç satır kod gerektirir.

Python Kullanarak (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 Kullanarak (CLI)

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

DuckDB Kullanımı

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. Özet: Büyük Veri Setleri Üzerine Sonuç

Küçük veri kümeleri ve doğrudan web uç noktaları için GeoJSON, güvenilir ve sorunsuz bir yardımcı format olarak kalır.

Ancak, büyük veri kümeleri için GeoParquet, her operasyonel kategoride nesnel olarak daha üstündür. Daha küçük dosya ayak izleri, önemli ölçüde daha düşük depolama maliyeti, neredeyse anlık uzamsal okuma ve modern bulut veri ambarlarıyla yerel entegrasyon sağlar.

Coğrafi veri iş akışlarınız aşırı büyük GeoJSON dosyalarının ağırlığı altında zorlanıyorsa, GeoParquet’e geçmek yapabileceğiniz en etkili altyapı iyileştirmelerinden biridir.


Sıkça Sorulan Sorular (SSS)

S1. GeoParquet resmi olarak tanınan bir CBS standardı mı? Evet, GeoParquet, Açık Coğrafi Uzamsal Konsorsiyumu (OGC) rehberliğinde sürdürülen resmi bir açık standarttır.

S2. GeoParquet dosyasını Leaflet veya Mapbox GL JS gibi web haritalama kütüphanelerinde doğrudan render edebilir miyim? GeoJSON gibi yerel olarak ayrıştırılamasa da, parquet-wasm gibi WebAssembly paketlerini kullanarak tarayıcılarda GeoParquet render edebilir veya dosyaları alım sırasında Vektör Damlalarına (PMTiles/MVT) dönüştürebilirsiniz.

S3. GeoParquet birden fazla koordinat referans sistemi (CRS) destekliyor mu? Evet, GeoJSON’un (RFC 7946 tarafından WGS 84 / EPSG:4326 ile kesin olarak sınırlanması) aksine, GeoParquet gömülü dosya meta verileri içinde doğrudan özel CRS tanımlarına izin verir.

S4. GeoParquet, büyük mekansal veri setleri için FlatGeobuf ile nasıl karşılaştırılır? FlatGeobuf, R-Tree mekansal indekslemesi kullanarak etkileşimli web haritalarına mekansal özellikleri doğrudan akışa almak için optimize edilmiştir, oysa GeoParquet yüksek performanslı sütunlu analiz, sıkıştırma ve büyük veri gölü depolama için tasarlanmıştır.

S5. GeoParquet dosyalarını QGIS gibi masaüstü GIS yazılımı içinde açabilir miyim? Evet, modern QGIS sürümleri (sürüm 3.28 ve üzeri) GeoParquet dosyalarını sürükle-bırak, görüntüleme ve stil verme işlemlerini üçüncü taraf eklentilere ihtiyaç duymadan destekler.

Ayrıca Bakınız

GIS Dosya Biçimleri FileFormat.com’da

Google Haritalar için En İyi 5 GIS Dosya Biçimi

Dosya Biçimi Haberleri

Dosya Biçimi Forumları