آخرین به‌روزرسانی: 2026-11-04

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

GeoParquet در مقابل GeoJSON: کدام فرمت GIS برای مجموعه‌ داده‌های بزرگ بهتر است؟

اگر تا به حال سعی کرده‌اید یک فایل GeoJSON حجمی ۲ گیگابایت را در QGIS باز کنید یا یک فایل مرز چند میلیون ردیفی چندضلعی را به یک نقشه تعاملی بارگذاری کنید، قبلاً احساس سردرگمی صفحه‌ی یخ‌زده و کرش ناشی از کمبود حافظه را تجربه کرده‌اید.

بیش از یک دهه، GeoJSON به عنوان زبان مشترک جهانی کارتوگرافی وب عمل کرده است. این فرمت شفاف، قابل خواندن برای انسان و به‌صورت پیش‌فرض توسط تقریباً تمام کتابخانه‌های نقشه‌برداری وب و APIهای REST در اینترنت پشتیبانی می‌شود.

با این حال، جریان‌های کاری مدرن GIS به‌طرز چشمگیری متفاوت از سال ۲۰۰۸ هستند. متخصصان جغرافیایی امروز به‌طور روزمره گیگابایت‌ها (یا ترابایت‌ها) از داده‌های تله‌متری موبایل IoT، ردپای ساختمان‌های سراسری، ماسک‌های تقسیم‌بندی به‌دست آمده از ماهواره و شبکه‌های آب و هوایی با فرکانس بالا را وارد می‌کنند.

هنگامی که بر روی مجموعه‌داده‌های در این مقیاس اعمال می‌شود، GeoJSON تنها سرعت را کاهش نمی‌دهد—بلکه به‌طور کامل معماری‌های داده را به تنگنا می‌کشاند.

معرفی GeoParquet، یک افزونه جغرافیایی باز و استاندارد شده برای Apache Parquet که در چارچوب Open Geospatial Consortium (OGC) در حال پرورش است.

در این راهنمای جامع، ما GeoParquet و GeoJSON را از نظر معماری، کارایی ذخیره‌سازی، توان خواندن/نوشتن، آمادگی برای ابر و راحتی توسعه‌دهندگان مقایسه می‌کنیم تا به سؤال مهمی پاسخ دهیم: کدام فرمت را برای مجموعه‌ داده‌های بزرگ انتخاب کنید؟

۱. معماری ساختاری: متن در مقابل ستونی باینری

برای درک اینکه چرا این فرمت‌ها در مقیاس بزرگ عملکرد متفاوتی دارند، باید زیرساخت‌ها را بررسی کنید که هر کدام چگونه مقادیر مختصات و متادیتای جدولی را نمایش می‌دهند.

+--------------------------------------------------------------+
| معیار ارزیابی |
| **قالب داده** |
| **نمایش هندسی** |
| **نسبت فشرده‌سازی** |
| **پروژکشن ستون** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **پوش‌داون پیش‌شرط فضایی** |
| **ذخیره‌سازی شیء ابری (S3/GCS)** |
| **قابلیت خوانایی انسانی** |
| **پشتیبانی مرورگر وب** |
| **نهاد استانداردسازی** |
+--------------------------------------------------------------+

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\" میلیون‌ها بار تکرار می‌شوند و باعث افزایش حجم فایل خام می‌شوند.
  • تبدیل پرهزینه رشته به عدد شناور: پردازشگر شما باید کاراکترهای متنی (\"-\", \"9\", \"7\", \".\", \"7\"...) را به اعداد شناور ۶۴ بیتی IEEE با دقت دو برابر تبدیل کند قبل از انجام هر عملیات فضایی.
  • نیازهای خواندن تک‌قطعه: پارسرهای استاندارد JSON باید کل فایل را به حافظه بارگذاری کنند تا مدل شیء سند (DOM) را بسازند. خواندن یک ویژگی نیاز به تجزیه هر ویژگی به‌صورت جداگانه دارد.

GeoParquet: ستونی‌محور، داده‌های باینری رمزگذاری‌شده

GeoParquet مستقیماً بر پایه Apache Parquet ساخته شده است و جداول فضایی را به‌صورت ستون‌به‌ستون نه ردیف‌به‌ردیف ذخیره می‌کند.

ویژگی‌هایی مانند county در بلوک‌های پیوسته ذخیره می‌شوند که امکان استفاده از تکنیک‌های پیشرفته فشرده‌سازی مانند رمزگذاری طول‑دنباله (RLE)، بسته‌بندی بیت و فشرده‌سازی دیکشنری را فراهم می‌کند. داده‌های هندسی به‌صورت Well-Known Binary (WKB) استاندارد شده‌اند و با متادیتای JSON جاسازی‌شده که سیستم‌های مرجع فضایی (CRS)، جعبه‌های محدود‌کننده و انواع هندسه را توصیف می‌کند، همراه هستند.

به دلیل اینکه GeoParquet باینری و ستونی است:

  • بدون هزینه تجزیه مختصات: هندسه‌ها به‌صورت مستقیم در قالب باینری ذخیره می‌شوند و از تبدیل‌های پرهزینه رشته به عدد شناور عبور می‌کنند.
  • پوش‌داون پیش‌بینی: اگر جریان کاری پایین‌دست شما فقط به ستون‌های county و pop_density نیاز داشته باشد، خواننده تنها آن افست‌های بایتی را از دیسک یا S3 دریافت می‌کند و به‌طور کامل ستون هندسه را نادیده می‌گیرد.
  • پارتیشن‌بندی گروه ردیف: فایل‌های Parquet رکوردها را به “Row Groups” خودکفا تقسیم می‌کنند (اغلب ۱۰۰,۰۰۰ تا ۱,۰۰۰,۰۰۰ ردیف در هر گروه) که همراه با آمار حداقل/حداکثر برای هر ستون هستند.

۲. مقایسه سر به سر: معیارهای اصلی

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)

۳. کارایی ذخیره‌سازی و معیارهای اندازه فایل

هنگامی که از هزاران به میلیون‌ها رکورد مقیاس می‌بریم، اختلافات ذخیره‌سازی به‌طرز چشمگیری افزایش می‌یابد.

در بنچمارک‌های استاندارد با استفاده از رکوردهای مکانی باز واقعی (مانند ردپای ساختمان‌های OpenStreetMap، مرزهای TIGER سرشماری ایالات متحده، و لاگ‌های AIS کشتی‌های جهانی)، GeoParquet به‌طور مداوم ۷۰٪ تا ۸۵٪ کاهش ذخیره‌سازی نسبت به GeoJSON خام را به دست می‌آورد و با یک ۲۰٪ تا ۴۰٪ اضافی بر .geojson.gz پیشی می‌گیرد.

چرا GeoParquet این‌قدر کوچک‌تر است؟

  1. Dictionary Encoding: ویژگی‌های رشته‌ای تکراری (مثلاً کدهای ایالت، طبقه‌بندی‌های استفاده از زمین) به‌جای ذخیره شدن مکرراً به‌صورت رشته‌های طولانی، به‌صورت اشاره‌گرهای عددی کوچک ایندکس می‌شوند.
  2. Compact Binary Coordinates: یک نقطه دو‑بعدی در GeoJSON حدود ۳۰ تا ۴۵ بایت متن ASCII ([-122.4194155, 37.7749295]) می‌گیرد. در WKB، همان جفت مختصات دقیقاً ۱۶ بایت نیاز دارد.
  3. Modern Compression Algorithms: Zstandard (Zstd) و Snappy آرایه‌های بایتی ستونی را بسیار مؤثرتر از Gzip استاندارد که می‌تواند متن ردیفی درهم‌تنیده را فشرده‌سازی کند، فشرده می‌کنند.

۴. عملکرد پرس‌وجو و جریان‌های کاری بومی‌ابر

بزرگ‌ترین عامل متمایزکننده برای مجموعه‌داده‌های بزرگ فقط ذخیره‌سازی نیست—بلکه تاخیر پرس‌وجو و استفاده از حافظه است.

۱. خواندن‌های انتخابی از طریق پیش‌بینی ستونی

تصور کنید یک مجموعه داده ملی از قطعات به حجم ۱۵ گیگابایت که شامل ۶۰ ویژگی (نام مالکین، شناسه‌های مالیاتی، تاریخ سند، کدهای زون‌بندی و مرزهای چندضلعی پیچیده) است.

  • در GeoJSON: اگر بخواهید متوسط ارزش ارزیابی‌شده املاک را بر حسب کد پستی محاسبه کنید، موتور تحلیلی شما باید تمام ۱۵ گیگابایت را دانلود و تجزیه کند، شامل میلیون‌ها راس مرز پیچیده.
  • در GeoParquet: موتورهای تحلیلی مانند DuckDB، Apache Sedona، Polars یا AWS Athena فقط ستون‌های zip_code و assessed_value را می‌خوانند. به جای انتقال ۱۵ گیگابایت، موتور شما کمتر از ۸۰ مگابایت را دانلود و اسکن می‌کند.

۲. درخواست‌های محدوده HTTP در ذخیره‌سازی ابری

GeoParquet به‌صورت یک فرمت جغرافیایی بومی‑ابری به‌راحتی کار می‌کند.

از آنجا که فایل‌های Parquet افست‌های داخلی و متادیتا را در فوتر فایل خود ذخیره می‌کنند، کتابخانه‌های کلاینت می‌توانند درخواست‌های HTTP GET Range: bytes=... را به ذخیره‌سازهای ابری مانند Amazon S3، Google Cloud Storage یا Azure Blob Storage ارسال کنند. به جای دانلود یک فایل چندگیگابایتی کامل، کلاینت فوتر را می‌خواند، افست‌های بایت دقیق که رکوردهای مرتبط در آن قرار دارند را شناسایی می‌کند و فقط زیرمجموعه‌های مورد نیاز را دانلود می‌کند.

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) ──────────────┘

۵. اکوسیستم نرم‌افزاری و پشتیبانی ابزارها

به‌طور تاریخی، مزیت اصلی 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: کتابخانه‌های سبک WebAssembly (مانند parquet-wasm و duckdb-wasm) اکنون به مرورگرهای وب امکان می‌دهند تا فایل‌های GeoParquet را مستقیماً بر روی دستگاه‌های کاربر بدون نیاز به سرور میانی GIS پرس و جو کنند.

۶. ماتریس تصمیم‌گیری عملی: چه زمانی از کدام استفاده کنیم؟

                                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 را انتخاب کنید:

  • داده‌های شما کمتر از ۵۰ مگابایت تا ۱۰۰ مگابایت هستند.
  • شما پاسخ‌های بار سبک را از یک REST API به کلاینت‌های فرانت‌اند برمی‌گردانید.
  • شما در حال ساخت نقشه‌های وب سبک با استفاده از Leaflet، MapLibre یا Mapbox GL JS بدون لایه‌های ترجمه میانی هستید.
  • شما به ویرایش یا بازرسی سریع دستی در یک ویرایشگر کد یا متن استاندارد نیاز دارید.

اگر GeoParquet را انتخاب کنید:

  • داده‌های شما بیش از ۱۰۰ مگابایت است یا شامل صدها هزار ویژگی فضایی پیچیده می‌شود.
  • شما دارایی‌های برداری را در ذخیره‌سازی ابجکت ابری (S3، GCS، MinIO، Azure Blob) ذخیره می‌کنید.
  • شما تجزیه و تحلیل‌های SQL فضایی، مهندسی ویژگی یا خطوط لوله یادگیری ماشین را با استفاده از Python، DuckDB، Spark یا Databricks اجرا می‌کنید.
  • شما می‌خواهید هزینه‌های ذخیره‌سازی را کاهش دهید، هزینه‌های خروجی شبکه را اجتناب کنید و از سقوط حافظه جلوگیری کنید.

۷. مثال مهاجرت: تبدیل GeoJSON به GeoParquet

تبدیل دارایی‌های فضایی موجود به GeoParquet تنها با چند خط کد انجام می‌شود.

استفاده از پایتون (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');

۸. خلاصه: حکم نهایی درباره مجموعه‌داده‌های بزرگ

برای مجموعه‌های داده کوچک و نقاط انتهایی وب مستقیم، GeoJSON همچنان یک قالب ابزار قابل اعتماد و بدون دردسر است.

با این حال، برای مجموعه‌های داده بزرگ، GeoParquet به‌طور عینی در هر دسته عملیاتی برتر است. این فرمت ردپای فایل‌های کوچکتری دارد، هزینه ذخیره‌سازی به‌طور قابل‌توجهی کمتر است، خواندن‌های فضایی تقریباً آنی هستند و یکپارچه‌سازی بومی با انبارهای داده ابری مدرن دارد.

اگر خطوط لوله جغرافیایی شما تحت فشار فایل‌های بزرگ‌حجم GeoJSON هستند، تغییر به GeoParquet یکی از مؤثرترین ارتقاءهای زیرساختی است که می‌توانید انجام دهید.

سوالات متداول (FAQ)

Q1. آیا GeoParquet یک استاندارد GIS به‌طور رسمی شناخته‌شده است؟ بله، GeoParquet یک استاندارد باز رسمی است که تحت راهنمایی کنسرسیوم جغرافیایی باز (OGC) نگهداری می‌شود.

Q2. آیا می‌توانم یک فایل GeoParquet را مستقیماً در کتابخانه‌های نقشه‌برداری وب مانند Leaflet یا Mapbox GL JS رندر کنم؟ اگرچه به‌صورت بومی مانند GeoJSON تجزیه نمی‌شود، می‌توانید GeoParquet را در مرورگرها با استفاده از بسته‌های WebAssembly مانند parquet-wasm یا با تبدیل فایل‌ها به کاشی‌های برداری (PMTiles/MVT) هنگام بارگذاری رندر کنید.

Q3. آیا GeoParquet از چندین سیستم مرجع مختصات (CRS) پشتیبانی می‌کند؟ بله، برخلاف GeoJSON (که به‌صورت سفت و سخت به WGS 84 / EPSG:4326 توسط RFC 7946 محدود است)، GeoParquet اجازه می‌دهد تعریف‌های CRS سفارشی را مستقیماً در متادیتای توکار فایل خود داشته باشد.

س.۴. GeoParquet چگونه با FlatGeobuf برای مجموعه داده‌های فضایی بزرگ مقایسه می‌شود؟ FlatGeobuf برای پخش ویژگی‌های فضایی به‌صورت مستقیم به نقشه‌های وب تعاملی با استفاده از ایندکس‌گذاری فضایی R-Tree بهینه‌سازی شده است، در حالی که GeoParquet برای تجزیه و تحلیل ستونی با عملکرد بالا، فشرده‌سازی و ذخیره‌سازی انبوه در دریاچه‌های داده‌ای طراحی شده است.

س.۵. آیا می‌توانم فایل‌های GeoParquet را در نرم‌افزارهای GIS دسکتاپ مانند QGIS باز کنم؟ بله، نسخه‌های مدرن QGIS (نسخه ۳.۲۸ و بالاتر) از کشیدن، رها کردن، مشاهده و استایل‌دهی به فایل‌های GeoParquet بدون نیاز به افزونه‌های شخص ثالث پشتیبانی می‌کنند.

موارد مرتبط

فرمت‌های فایل GIS در FileFormat.com

۵ فرمت برتر فایل GIS برای Google Maps

اخبار فرمت فایل

انجمن‌های فرمت فایل