Viimeksi päivitetty: 2026-11-04

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

GeoParquet vs. GeoJSON: Mikä GIS-muoto on parempi suurille tietoaineistoille?

Jos olet koskaan yrittänyt avata 2 GB:n GeoJSON-tiedostoa QGIS:ssä tai ladata miljoonia rivejä sisältävää polygonirajapistetiedostoa interaktiiviseen karttaan, tiedät jo sen kylmän tunteen, kun näyttö jäätyy ja tapahtuu muistin loppuminen.

Yli kymmenen vuoden ajan GeoJSON on toiminut verkkokartografian yleiskielenä. Se on läpinäkyvä, ihmisluettava ja lähes jokaisen verkkokartoituskirjaston ja REST‑API:n tukema suoraan käyttöön.

Kuitenkin nykyaikaiset GIS-työvirrat näyttävät radikaalisti erilaisilta kuin vuonna 2008. Nykyiset paikkatietojen ammattilaiset ottavat säännöllisesti vastaan gigatavuja (tai teratavuja) IoT-mobiilitelematiikkaa, koko maan rakennuspiirroksia, satelliittien tuottamia segmentointimaskia ja korkean taajuuden ilmastogridit.

Kun sitä sovelletaan näin suuriin tietoaineistoihin, GeoJSON ei pelkästään hidasta – se aiheuttaa täydellisen pullonkaulan data‑arkkitehtuureissa.

Tässä astuu kuvaan GeoParquet, avoin, standardoitu paikkatietolaajennus Apache Parquetille, joka kehittyy Open Geospatial Consortium (OGC) -organisaation sisällä.

Tässä kattavassa oppaassa vertailemme GeoParquetia ja GeoJSONia arkkitehtuurin, tallennustehokkuuden, luku-/kirjoitusnopeuden, pilvi‑valmiuden ja kehittäjäergonomian osalta vastataksemme kriittiseen kysymykseen: Minkä formaatin sinun tulisi valita suurille tietoaineistoille?

1. Rakennearkkitehtuuri: Teksti vs. Binäärinen sarakepohjainen

Ymmärtääksesi, miksi nämä formaatit toimivat niin eri tavalla mittakaavassa, sinun on katsottava moottorin sisälle, miten kukin esittää koordinaattiarvot ja taulukkometatiedot.

+--------------------------------------------------------------+
| Arviointimittari |
| **Tietomuoto** |
| **Geometrinen esitys** |
| **Pakkaussuhde** |
| **Sarakkeen projekti** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Paikallisen predikaatin alasajo** |
| **Pilviobjektivarasto (S3/GCS)** |
| **Ihmisen luettavuus** |
| **Selaintuki** |
| **Standardointielin** |
+--------------------------------------------------------------+

GeoJSON: Rivisuuntainen, Tekstikoodattu JSON

GeoJSON esittää tiedot JSON-objektien taulukkona. Jokainen yksittäinen kohde toistaa eksplisiittisesti attribuuttien avaimet taulukon rinnalla, jossa on merkkijonona koodattuja liukulukuja:

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

Koska GeoJSON on tekstipohjainen:

  • Toistuvat skeemat: Kenttien nimet kuten "properties", "type" ja "coordinates" toistuvat miljoonia kertoja, kasvattaen raak tiedoston kokoa.
  • Kallis merkkijono‑liukuluku-muunnos: CPU:n täytyy jäsentää tekstimerkit ("-", "9", "7", ".", "7"...) 64-bittisiksi IEEE double‑precision liukuluvuiksi ennen minkään spatiaalisen operaatioiden suorittamista.
  • Monoliittiset lukuvaatimukset: Standardi JSON‑jäsennin täytyy ladata koko tiedosto muistiin rakentaakseen Document Object Model (DOM) -rakenteen. Yhden attribuutin lukeminen vaatii jokaisen yksittäisen kohteen jäsentämisen.

GeoParquet: Sarakesuuntainen, Binäärikoodattu data

GeoParquet rakentuu suoraan Apache Parquet-muotoon, tallentaen spatiaalit taulut sarake kerrallaan riveittäin.

Attribuutit kuten county tallennetaan peräkkäisiin lohkoihin, mikä mahdollistaa kehittyneet pakkaustekniikat, kuten juoksevan pituuden koodaus (RLE), bittipakkaus ja sanakirjapakkaus. Geometriatiedot standardoidaan Well-Known Binary (WKB) -muotoon, ja niihin liitetään upotettu JSON-metatieto, joka kuvaa spatiaalireferenssijärjestelmät (CRS), raja-alueet ja geometria-tyypit.

Koska GeoParquet on binaarinen ja sarakepohjainen:

  • Nollakoordinaattien jäsentämiskustannus: Geometriat tallennetaan suoraan binaarimuodossa, ohittaen kalliit merkkijono-float -muunnokset.
  • Projektio-pushdown: Jos alavirtaisen työnkulun tarvitsee vain county- ja pop_density-sarakkeet, lukija hakee vain näiden tavuaikojen siirrososoitteet levystä tai S3:sta, ohittaen kokonaan geometria-sarakkeen.
  • Rivi-ryhmän jakaminen: Parquet-tiedostot jakavat tietueet itsenäisiin “Row Groups” -ryhmiin (usein 100 000–1 000 000 riviä kussakin), sisältäen min/max‑tilastot jokaiselle sarakkeelle.

2. Suora vertailu: Keskeiset mittarit

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. Tallennustehokkuus ja tiedostokoon vertailuarvot

Kun skaalataan tuhansista miljooniin tietueisiin, tallennuserot kasvavat dramaattisesti.

Standardisissa vertailuissa, joissa käytetään todellisia avoimia spatiaalitietueita (kuten OpenStreetMap‑rakennusten ääriviivat, US Census TIGER -rajat ja globaalit alusten AIS‑lokit), GeoParquet saavuttaa säännöllisesti 70 %–85 % tallennussäästöt verrattuna raakaan GeoJSONiin, ja päihittää .geojson.gz-tiedoston lisä 20 %–40 %.

Miksi GeoParquet on niin paljon pienempi?

  1. Dictionary Encoding: Toistuvat merkkijonoattribuutit (esim. osavaltion koodit, maankäytön luokitukset) indeksoidaan pieniksi kokonaislukupointeiksi sen sijaan, että ne tallennettaisiin toistuvasti pitkinä merkkijonoina.
  2. Compact Binary Coordinates: 2D‑piste GeoJSONissa vie noin 30–45 tavua ASCII‑tekstiä ([-122.4194155, 37.7749295]). WKB:ssä sama koordinaattipari vaatii tarkalleen 16 tavua.
  3. Modern Compression Algorithms: Zstandard (Zstd) ja Snappy pakkaavat sarakepohjaiset tavutaulukot paljon tehokkaammin kuin tavallinen Gzip pystyy pakkaamaan lomitetun rivi‑pohjaisen tekstin.

4. Kyselysuorituskyky ja pilvipohjaiset työnkulut

Suurimpana erottavana tekijänä suurille tietoaineistoille ei ole pelkkä tallennus—se on kyselyn viive ja muistin käyttö.

1. Valikoivat lukemiset sarakeprojektioiden avulla

Kuvittele 15 GB:n kansallinen kiinteistörekisteri, joka sisältää 60 attribuuttia (omistajien nimet, verotunnisteet, omistusoikeushistoria, kaavamääräykset ja monimutkaiset monikulmioiden rajat).

  • In GeoJSON: Jos haluat laskea keskimääräisen arvioidun kiinteistöarvon postinumerokohtaisesti, analyysimoottorisi täytyy ladata ja jäsentää kaikki 15 GB, mukaan lukien miljoonat monimutkaiset raja‑solmut.
  • In GeoParquet: Analyysimoottorit kuten DuckDB, Apache Sedona, Polars tai AWS Athena lukevat vain zip_code- ja assessed_value-sarakkeet. Sen sijaan, että siirtäisit 15 GB:n, moottorisi lataa ja skannaa alle 80 MB.

2. HTTP-aluepyynnöt pilvitallennuksessa

GeoParquet toimii saumattomasti pilvipohjaisena paikkatietomuotona.

Koska Parquet-tiedostot tallentavat sisäiset siirrososoitteet ja metatiedot tiedoston alatunnisteeseen, asiakasohjelmistokirjastot voivat lähettää HTTP GET Range: bytes=... -pyyntöjä pilviobjektivarastoihin kuten Amazon S3, Google Cloud Storage tai Azure Blob Storage. Sen sijaan, että ladattaisiin koko monigigatavun tiedosto, asiakas lukee alatunnisteen, tunnistaa tarkat tavujaksojen siirrososoitteet, joissa relevantit tietueet sijaitsevat, ja lataa vain tarvittavat osajoukot.

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. Ohjelmistoympäristö ja työkalutuki

Historiallisesti GeoJSON:n ensisijainen etu oli universaali työkalutuki. Vaikka tämä pitää paikkansa selaimen ympäristöissä, GeoParquetin ekosysteemi on kehittynyt nopeasti:

  • Työpöytä GIS: Alkuperäinen luku/kirjoitustuki QGIS 3.28+, ArcGIS Pro ja GDAL/OGR 3.5+.
  • Analytiikkamoottorit & Kielet: Nopeat vektoroidut luku- ja kirjoitusominaisuudet Pythonissa (GeoPandas, pyarrow), R:ssä (sf), DuckDB:ssä (spatiaalisen laajennuksen kautta), Apache Sedonassa ja Snowflakessa.
  • Big Data -putket: Alkuperäinen integraatio Apache Sparkin, Trinon, Preston ja Databricksin kanssa.
  • Asiakaspuolen verkkokartat: Kevyet WebAssembly-kirjastot (kuten parquet-wasm ja duckdb-wasm) mahdollistavat nyt verkkoselaimien kysellä GeoParquet-tiedostoja suoraan asiakaslaitteilla ilman erillistä GIS-välikerrospalvelinta.

6. Käytännön päätösmatriisi: Milloin käyttää kumpaakin?

                                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

Valitse GeoJSON, jos:

  • Tietoaineistosi on alle 50–100 MB.
  • Palautat kevyitä payload-vastauksia REST‑API:sta etupään asiakkaille.
  • Rakennat kevyitä verkkokarttoja käyttäen Leafletia, MapLibreä tai Mapbox GL JS:ää ilman välillisiä käännöskerroksia.
  • Tarvitset nopeaa manuaalista muokkausta tai tarkastelua tavallisessa koodin- tai tekstieditorissa.

Valitse GeoParquet, jos:

  • Tietoaineistosi ylittää 100 MB:n tai se sisältää satoja tuhansia monimutkaisia spatiaalisia ominaisuuksia.
  • Tallennat vektorivarantoja pilven objektitallennustilaan (S3, GCS, MinIO, Azure Blob).
  • Suoritit spatiaalista SQL-analytiikkaa, ominaisuuksien suunnittelua tai koneoppimisen putkistoja käyttäen Pythonia, DuckDB:tä, Sparkia tai Databricksia.
  • Haluat vähentää tallennuskustannuksia, välttää verkon ulostulomaksuja ja poistaa muistin kaatumiset.

7. Siirtymäesimerkki: GeoJSONin muuntaminen GeoParquetiksi

Olemassa olevien spatiaalisten varantojen muuntaminen GeoParquet-muotoon vaatii vain muutaman koodirivin.

Pythonin käyttö (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:n käyttö (CLI)

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

DuckDB:n käyttö

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. Yhteenveto: Tuomio suurista tietoaineistoista

Pienille tietoaineistoille ja suoran verkkopäätepisteen yhteydessä GeoJSON on edelleen luotettava, vaivaton hyötymuoto.

Kuitenkin suurille tietoaineistoille GeoParquet on objektiivisesti parempi kaikissa operatiivisissa kategorioissa. Se tarjoaa pienemmät tiedostokoot, merkittävästi alhaisemman tallennuskuorman, lähes välittömät spatiaalilukemiset ja natiivisen integraation nykyaikaisiin pilven tietovarastoihin.

Jos geospatiaaliputkistosi valittavat ylikoonien GeoJSON-tiedostojen painon alla, siirtyminen GeoParquetiin on yksi tehokkaimmista infrastruktuuripäivityksistä, joita voit tehdä.

Usein kysytyt kysymykset (FAQ)

Q1. Onko GeoParquet virallisesti tunnustettu GIS-standardi? Kyllä, GeoParquet on virallinen avoin standardi, jota ylläpidetään Open Geospatial Consortiumin (OGC) ohjauksessa.

Q2. Voinko renderöidä GeoParquet-tiedoston suoraan web-kartoituskirjastoissa kuten Leaflet tai Mapbox GL JS? Vaikka sitä ei parseerata natiivisti kuten GeoJSON, voit renderöidä GeoParquetin selaimissa käyttämällä WebAssembly-paketteja kuten parquet-wasm tai muuntamalla tiedostot vektoritiileiksi (PMTiles/MVT) sisäänlatauksen yhteydessä.

Q3. Tukeeko GeoParquet useita koordinaattijärjestelmiä (CRS)? Kyllä, toisin kuin GeoJSON (joka on tiukasti rajoitettu WGS 84 / EPSG:4326 -standardiin RFC 7946:n mukaan), GeoParquet sallii mukautetut CRS-määritelmät suoraan upotetussa tiedoston metadatassa.

Q4. Miten GeoParquet vertautuu FlatGeobufiin suurissa spatiaalisissa dataseteissä? FlatGeobuf on optimoitu spatiaalisten ominaisuuksien suoratoistoon suoraan interaktiivisiin verkkokarttoihin R-puun spatiaalisen indeksoinnin avulla, kun taas GeoParquet on suunniteltu korkean suorituskyvyn sarakeanalytiikkaan, pakkaamiseen ja massiiviseen datalake-varastointiin.

Q5. Voinko avata GeoParquet-tiedostoja työpöytä-GIS-ohjelmistossa kuten QGIS? Kyllä, QGIS:n nykyaikaiset versiot (versio 3.28 ja uudemmat) tukevat GeoParquet-tiedostojen vetämistä, pudottamista, katselua ja tyylittämistä ilman kolmannen osapuolen lisäosia.

Katso myös

GIS-tiedostomuodot FileFormat.comissa

Top 5 GIS-tiedostomuotoa Google Mapsille

Tiedostomuotojen uutiset

Tiedostomuotojen foorumit