עודכן לאחרונה: 2026-11-04

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

GeoParquet מול GeoJSON: איזה פורמט GIS הוא טוב יותר למערכי נתונים גדולים?

אם אי פעם ניסית לפתוח קובץ GeoJSON בגודל 2 GB ב‑QGIS או לטעון קובץ גבולות פוליגון עם מיליוני שורות למפה אינטראקטיבית, אתה כבר מכיר את התחושה של מסך קפוא ונפילת זיכרון.

במשך יותר מעשור, GeoJSON משמש כשפה אוניברסלית של קרטוגרפיה אינטרנטית. הוא שקוף, קריא לבני אדם, ותומך בו כמעט כל ספריית מיפוי אינטרנטית ו‑REST API באינטרנט באופן מיידי.

עם זאת, זרימות עבודה מודרניות של GIS נראות שונה באופן רדיקלי ממה שהיו בשנת 2008. המומחים הגיאוספיישליים של היום צורכים באופן שגרתי גיגבייטים (או טרהבייטים) של טלמטריית תנועה של IoT, footprints של בניינים ברחבי המדינה, מסכות סגמנטציה שמקורן בלוויין, ורשתות אקלים בתדירות גבוהה.

כאשר מוחל על מערכי נתונים בקנה מידה זה, GeoJSON לא רק מתאחר—הוא חוסם לחלוטין את ארכיטקטורות הנתונים.

היכנסו ל‑GeoParquet, הרחבה גיאוספיישלית פתוחה וסטנדרטית ל‑Apache Parquet המתפתחת במסגרת ה‑Open Geospatial Consortium (OGC).

במדריך המקיף הזה, אנו משווים בין GeoParquet ל-GeoJSON מבחינת ארכיטקטורה, יעילות אחסון, קצב קריאה/כתיבה, מוכנות לענן, ונוחות למפתחים, כדי לענות על שאלה קריטית: איזה פורמט לבחור עבור מערכי נתונים גדולים?

1. ארכיטקטורה מבנית: טקסט מול בינארי בעמודות

כדי להבין מדוע פורמטים אלה מתפקדים בצורה שונה בקנה מידה גדול, עליך להסתכל מתחת למכסה ולראות כיצד כל אחד מייצג ערכי קואורדינטות ונתוני מטא-טבלה.

+--------------------------------------------------------------+
| מדד הערכה |
| **פורמט נתונים** |
| **ייצוג גיאומטרי** |
| **יחס דחיסה** |
| **הצגת עמודות** |
+--------------------------------------------------------------+
                               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"...) למספרים צפים של 64‑ביט IEEE ברמת דיוק כפולה לפני ביצוע כל פעולה מרחבית.
  • דרישות קריאה מונוליטיות: מפרשי JSON סטנדרטיים חייבים לטעון את כל הקובץ לזיכרון כדי לבנות את מודל האובייקט של המסמך (DOM). קריאת מאפיין אחד דורשת ניתוח של כל תכונה בודדת.

GeoParquet: מבוסס עמודות, נתונים מקודדים בינארית

GeoParquet נבנה ישירות על Apache Parquet, מאחסן טבלאות מרחביות עמודה-בעמודה במקום שורה-בשורה.

תכונות כמו county מאוחסנות בחסימות רצופות, מה שמאפשר טכניקות דחיסה מתקדמות כגון קידוד רצף (RLE), אריזת ביטים, ודחיסת מילון. נתוני הגאומטריה מתוקננים כ-Well-Known Binary (WKB), מלווה במטא-דאטה JSON משובץ המתאר מערכות ייחוס מרחביות (CRS), תיבות גבול, וסוגי גאומטריה.

מכיוון ש-GeoParquet הוא בינארי ועמודי:

  • עלות אפס בפענוח קואורדינטות: הגאומטריות מאוחסנות ישירות בצורה בינארית, מדלגות על המרות מחרוזת למספר רציונלי היקרות.
  • דחיפת פרויקט: אם זרימת העבודה שלך במ downstream דורשת רק את העמודות county ו-pop_density, הקורא מושך רק את ה‑offsetים של הבייטים האלה מהדיסק או מ‑S3, מדלג לחלוטין על עמודת הגאומטריה.
  • חלוקת קבוצות שורות: קבצי Parquet מחלקים רשומות ל"Row Groups" עצמאיות (לעיתים 100,000 עד 1,000,000 שורות בכל קבוצה) עם סטטיסטיקות מינימום/מקסימום לכל עמודה.

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 משיג באופן שגרתי הפחתות אחסון של 70% עד 85% בהשוואה ל-GeoJSON גולמי, ומקדים את .geojson.gz בעוד 20% עד 40%.

למה GeoParquet קטן כל כך?

  1. קידוד מילון: תכונות מחרוזת חוזרות (למשל קודי מדינות, סיווגי שימושי קרקע) מאונדקסות למצביעים שלמים קטנים במקום להישמר באופן חוזר כמחרוזות ארוכות.
  2. קואורדינטות בינאריות קומפקטיות: נקודה דו‑ממדית ב-GeoJSON תופסת כ‑30 עד 45 בתים של טקסט ASCII ([-122.4194155, 37.7749295]). ב‑WKB, זוג הקואורדינטות הזה דורש בדיוק 16 בתים.
  3. אלגוריתמי דחיסה מודרניים: Zstandard (Zstd) ו‑Snappy דוחסים מערכי בתים בטור בצורה יעילה הרבה יותר מאשר Gzip סטנדרטי יכול לדחוס טקסט מבוסס שורות משולבות.

4. ביצועי שאילתות וזרימות עבודה מבוססות ענן

הגורם המבדיל הגדול ביותר עבור מערכי נתונים גדולים אינו רק האחסון—זה זמני השאילתה וניצול הזיכרון.

1. קריאות סלקטיביות באמצעות פרויקטור עמודות

דמיינו מסד נתונים לאומי של חבילות בגודל 15 ג״ב המכיל 60 תכונות (שמות בעלים, מזהי מס, היסטוריית מסמכים, קודי תכנון, וגבולות מרובי פוליגונים מורכבים).

  • ב-GeoJSON: אם ברצונכם לחשב את ערך הנכס המוערך הממוצע לכל מיקוד, מנוע האנליזה שלכם צריך להוריד ולנתח את כל 15 ג״ב, כולל מיליוני קודקודי גבול מורכבים.
  • ב-GeoParquet: מנועי אנליזה כגון DuckDB, Apache Sedona, Polars, או AWS Athena קוראים רק את העמודות zip_code ו-assessed_value. במקום להעביר 15 ג״ב, המנוע שלכם מוריד וסורק פחות מ‑80 מ״ב.

2. בקשות טווח 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) ──────────────┘

5. אקוסיסטם תוכנה ותמיכה בכלים

היסטורית, היתרון העיקרי של GeoJSON היה תמיכה אוניברסלית בכלים. בעוד שזה עדיין נכון עבור סביבות דפדפן, האקוסיסטם של GeoParquet התבגר במהירות:

  • GIS לשולחן העבודה: תמיכה מקומית בקריאה/כתיבה ב-QGIS 3.28+, ArcGIS Pro, ו‑GDAL/OGR 3.5+.
  • מנועים ו‑שפות אנליטיות: יכולות קריאה/כתיבה וקטוריות מהירות ב‑Python (GeoPandas, pyarrow), R (sf), DuckDB (דרך הרחבה מרחבית), Apache Sedona, ו‑Snowflake.
  • צינורות נתוני‑ביג: אינטגרציה מקומית עם Apache Spark, Trino, Presto, ו‑Databricks.
  • מפות אינטרנט בצד הלקוח: ספריות WebAssembly קלות משקל (כגון parquet-wasm ו‑duckdb-wasm) מאפשרות כעת לדפדפנים לשאול קבצי GeoParquet ישירות במכשירי הלקוח ללא שרת GIS ייעודי.

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 מ״ב, או מכיל מאות אלפי תכונות מרחביות מורכבות.
  • אתה מאחסן נכסי וקטור באחסון אובייקטים בענן (S3, GCS, MinIO, Azure Blob).
  • אתה מריץ ניתוחי SQL מרחביים, הנדסת תכונות, או צינוריות למידת מכונה באמצעות Python, DuckDB, Spark או Databricks.
  • אתה רוצה להפחית עלויות אחסון, להימנע מתשלומי יציאת רשת, ולמחוק קריסות זיכרון.

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)

שאלה 1. האם GeoParquet הוא תקן GIS מוכר רשמית? כן, GeoParquet הוא תקן פתוח רשמי המתוחזק תחת ההכוונה של הקונסורציום הגיאו-מרחבי הפתוח (OGC).

שאלה 2. האם ניתן להציג קובץ GeoParquet ישירות בספריות מיפוי אינטרנטיות כמו Leaflet או Mapbox GL JS? למרות שלא מתפרש באופן מקורי כמו GeoJSON, ניתן להציג GeoParquet בדפדפנים באמצעות חבילות WebAssembly כגון parquet-wasm או על‑ידי המרת הקבצים ל‑Vector Tiles (PMTiles/MVT) בעת הקליטה.

שאלה 3. האם GeoParquet תומך במערכות ייחוס קואורדינטות מרובות (CRS)? כן, בניגוד ל‑GeoJSON (שמוגבל בקפדנות ל‑WGS 84 / EPSG:4326 לפי RFC 7946), GeoParquet מאפשר הגדרות CRS מותאמות אישית ישירות בתוך מטא‑נתוני הקובץ המוטמע שלו.

שאלה 4. איך GeoParquet משווה ל-FlatGeobuf עבור מערכי נתונים מרחביים גדולים? FlatGeobuf מותאם לשידור תכונות מרחביות ישירות למפות אינטרנט אינטראקטיביות באמצעות אינדקס מרחבי R-Tree, בעוד GeoParquet נועד לניתוח עמודתי בעל ביצועים גבוהים, דחיסה, ואחסון מאגרי נתונים גדולים של אגמי נתונים.

שאלה 5. האם ניתן לפתוח קבצי GeoParquet בתוך תוכנת GIS לשולחן העבודה כמו QGIS? כן, גרסאות מודרניות של QGIS (גרסה 3.28 ומעלה) תומכות בגרירה, שחרור, צפייה ועיצוב קבצי GeoParquet ללא צורך בתוספים של צד שלישי.

ראה גם

פורמטים של קבצי GIS ב-FileFormat.com

חמשת פורמטי הקבצים של GIS עבור Google Maps

חדשות פורמט קבצים

פורומי פורמט קבצים