Labākie GIS failu formāti mobilajām lietojumprogrammām: galīgais izstrādātāju ceļvedis

Mobilās ĢIS lietotnes saskaras ar aparatūras un tīkla ierobežojumiem, ko galddatora ĢIS sistēmas nekad neizjūt. Portatīvie ierīces darbojas ar ierobežotu RAM, mainīgu baterijas darbības laiku un pārtraukta vai neesoša mobilo sakaru savienojuma lauku apstākļos. Mēģinājums parsēt monolītu, slikti strukturētu telpisko datu kopu iOS vai Android ierīcē noved pie lietotnes avārijām, lēnas skārienekrāna reakcijas un smagas baterijas iztukšošanas.

Pareiza ģeogrāfisko datu konteineru izvēle ir ietekmīgākais tehniskais lēmums, izstrādājot lauka inspekcijas rīkus, loģistikas informācijas paneļus, bezsaistes pārgājienu sekotājus vai pilsētplānošanas lietojumprogrammas. Šis ceļvedis sadala populārākos telpiskos formātus mobilajām vidēm, salīdzina to darbības kompromisus un sniedz praktiskus ieteikumus, balstoties uz reāliem lietošanas gadījumiem.

Tehniskie ierobežojumi mobilajām GIS vidēm

Pirms formātu izvērtēšanas, apsveriet četrus galvenos ierobežojumus, kas nosaka mobilās veiktspējas:

1. Atmiņas piešķiršana (RAM): Mobilās operētājsistēmas agresīvi aptur fona procesus vai smagas kaudzes uzdevumus. Neindeksētu vektoru slāņu ielāde tieši atmiņā izraisa ātru Atmiņas izsīkuma (OOM) pārtraukumu.
2. Bezsaistes I/O un nejauša piekļuve: Lauka darbinieki bieži zaudē tīkla piekļuvi. Glabāšanas dzinējam jāatbalsta indeksētas, diska līmeņa telpiskās vaicājumu (piemēram, R-Tree) funkcijas, lai lietojumprogramma lasītu tikai pašlaik skatā esošos elementus, nevis skenētu visu failu.
3. Datu pārslodze un joslas platums: Smagu datu pārsūtīšana pāri 3G/4G/5G tīkliem iztukšo ierīču baterijas un patērē dārgas datu kvotas.
4. Lasīšanas/rakstīšanas mainība: Mobilās pārbaudes darbplūsmas pieprasa lauka personālam ierakstīt GPS koordinātas, pievienot piezīmes, atjaunināt statusa atribūtus un sinhronizēt izmaiņas atpakaļ uz centrālajām datubāzēm, nepārkāpjot faila integritāti.

Detalizēta novērtējuma: Vislabākie GIS formāti mobilajām lietotnēm

1. GeoPackage (.gpkg) — Neapstrīdētais nozares zelta standarts

Uzturēts kā atvērtā standarta no Open Geospatial Consortium (OGC), GeoPackage ir izveidots uz iebūvēta SQLite datubāzes konteinerā.

• Kāpēc tas izceļas mobilajās ierīcēs: SQLite ir iebūvēts gan Android, gan iOS operētājsistēmās. GeoPackage vaicāšana neprasa smagu pielāgotu parsēšanas slāni. Tas izmanto telpisko indeksēšanu (R-Tree) jau no sākuma, ļaujot lietojumprogrammām ātri izgūt telpiskās robežkastes fragmentus, neielādējot visu datubāzi atmiņā (RAM).
• Galvenās iespējas: Tas atbalsta gan vektoru datus, gan rastra flīžu piramīdas vienā kompaktā binārajā failā. Tas apstrādā vairākus slāņus, sarežģītas atribūtus, shēmas definīcijas un tiešus telpiskos atjauninājumus (INSERT, UPDATE, DELETE).
• Vislabāk piemērots: Bezsaistes datu vākšanai, lauka inspekcijas lietotnēm (piemēram, QField, Mergin Maps), aktīvu pārvaldībai un jauktai vektoru/rastra bezsaistes glabāšanai.

2. MBTiles (.mbtiles) — Vislabāk piemērots pamata kartēm un rastra attēliem

Sākotnēji izstrādājis Mapbox, MBTiles ir arī uz SQLite balstīta specifikācija, kas īpaši izstrādāta, lai paketētu iepriekš renderētās kartes flīzes.

• Kāpēc tas izceļas mobilajās ierīcēs: MBTiles atrisina failu sistēmas šaurumu. Glabājot desmitiem tūkstošu atsevišķu flīžu attēlu (.png vai .pbf) tieši mobilajās failu sistēmās, veiktspēja pasliktinās. Šo flīžu paketēšana vienā SQLite konteinerā ļauj veikt gandrīz tūlītējus meklējumus, izmantojot standarta SQL flīžu koordinātu indeksēšanu (z, x, y).
• Vektoru flīzes (MVT) MBTiles iekšpusē: Kombinējot ar Mapbox Vector Tiles (MVT), MBTiles nodrošina ārkārtīgi asus, augstas veiktspējas pamata kartes, kuras var dinamiski pārveidot ierīcē, izmantojot GPU renderēšanu, ar minimālu glabāšanas prasību.
• Vislabāk piemērots: Bezsaistes pamatskartēm, gaisa attēlu pamata slāņiem, pārgājienu kartēm un navigācijas displejiem.

3. FlatGeobuf (.fgb) — Vislabāk piemērots augstas veiktspējas tikai lasāmai vektoru straumei

FlatGeobuf ir mūsdienīgs binārais kodēšanas formāts vektordatiem, kas balstīts uz FlatBuffers.

• Kāpēc tas izceļas mobilajās ierīcēs: Atšķirībā no GeoJSON, FlatGeobuf neprasa deserializācijas soli. CPU lasa datus tieši no binārā straumes, neveidojot starpējus atmiņas objektus. Tas ietver iebūvētu telpisko indeksu (saspiests Hilberta R-koks). FlatGeobuf ir īpaši spēcīgs pār HTTP/HTTPS: mobilie klienti var izsūtīt HTTP diapazona pieprasījumus, lai lejupielādētu tikai to vektordatu daļu, kas aptver ierīces pašreizējo skatlogu.
• Ierobežojumi: FlatGeobuf būtībā ir arhīva/straumes formāts; tas nav paredzēts tiešai datubāzes rediģēšanai vai lauku ierakstu manipulācijai.
• Vislabāk piemērots: Ātra straume smagiem vektordatu kopumiem (piemēram, valsts mēroga zemes gabali, kontūras, ceļu tīkli) ar gandrīz tūlītēju skatlogu attēlošanu.

4. GeoJSON (.geojson) — Vislabāk piemērots tikai vieglām API slodēm

GeoJSON ir atvērts, cilvēkiem lasāms standarts, kas balstīts uz JavaScript Object Notation.

• Kāpēc tas ir riskants lieliem datu kopumiem: Tā kā GeoJSON ir teksta formāts un nav indeksēts, mobilajām ierīcēm jāparsē viss virkne un jāizveido katrs koordināts un īpašība atmiņā pirms renderēšanas. 40 MB GeoJSON fails var ātri izaugt līdz vairākām simtiem megabaitiem kaudzes atmiņā, izraisot mobilā klienta avāriju.
• Kad to izmantot: Ideāli piemērots mazu darījumu slodžu pārsūtīšanai (piemēram, viena maršruta ģeometrija, 50 tuvumā esoši interesējoši punkti vai ātri API veidlapas iesniegumi).

5. Shapefile (.shp) — Kāpēc to jāizvairās mobilajās ierīcēs

Izstrādāts 1990. gados uzņēmuma Esri, Shapefile joprojām ir izplatīts uz vecākām darbvirsmas sistēmām, taču tas ir slikti piemērots mobilai izstrādei:

• Tas prasa vairākus saistītus failus (.shp, .shx, .dbf, .prj), radot failu sinhronizācijas un pakotņu riskus.
• Lauku nosaukumi tiek saīsināti līdz 10 rakstzīmēm.
• Maksimālais faila izmērs ir stingri ierobežots līdz 2 GB.
• Tam trūkst mūsdienīgu kodēšanas standartus, bieži izraisot rakstzīmju kopas bojājumus ar starptautisku tekstu.

Salīdzinājumu matrica: Mobilie GIS formāti

Praktiski arhitektūras ieteikumi

Veidojot ražošanas līmeņa mobilo GIS arhitektūru, izvairieties no atkarības no viena formāta visām uzdevumiem. Mūsdienīgas GIS lietotnes izmanto daudzpakāpju glabāšanas pieeju:

1. Bezsaistes lauka rediģēšanai un datu tveršanai: Izmantojiet GeoPackage (.gpkg). Tā iebūvētais SQLite pamats nodrošina ACID atbilstību, vairāku tabulu savienojumus, nevainojamus ģeometriskos atjauninājumus un uzticamu bezsaistes kešatmiņu.
2. Bezsaistes pamata kartēm un flīžu pārklājumiem: Izmantojiet MBTiles (.mbtiles), kas satur Mapbox Vector Tiles (MVT). Tas uztur failu glabāšanu kārtīgu un pārvieto renderēšanu uz mobilā GPU.
3. Tiešai mākoņa-uz-mobilo vektoru sinhronizācijai: Straumējiet ģeometrijas, izmantojot FlatGeobuf (.fgb) caur HTTP diapazona pieprasījumiem milzīgām tikai lasāmajām slāņiem, vai arī vieglus GeoJSON fragmentus individuāliem punktu atjauninājumiem un reāllaika brīdinājumiem.

SEO metadati un ieteiktie virsraksti

Virsraksta tagu ieteikumi

1. Labākais GIS faila formāts mobilajām lietotnēm: veiktspēja, glabāšana un bezsaistes ceļvedis
2. Mobilā GIS arhitektūra: kāpēc GeoPackage un MBTiles pārspēj mantotās formātus
3. Vadošie GIS formāti mobilās lietotnes izstrādei: ātrums, atmiņa un bezsaistes sinhronizācija

Meta apraksta ieteikumi

1. Atklājiet labākos GIS failu formātus mobilajām lietotnēm. Salīdziniet GeoPackage, MBTiles, FlatGeobuf un GeoJSON atmiņas efektivitātes, bezsaistes sinhronizācijas un ātras renderēšanas ziņā.
2. Veidojot mobilo kartēšanas lietotni? Uzziniet, kuri telpiskie datu formāti novērš atmiņas avārijas, atbalsta bezsaistes lauka rediģēšanu un nodrošina zibspiediens ātru renderēšanu.
3. Izstrādātāja ceļvedis mobilajiem GIS failu formātiem. Uzziniet, kāpēc GeoPackage un MBTiles dominē lauka datu vākšanā, kamēr vecākie Shapefile formāti nepietiek.

Biežāk uzdotie jautājumi

Kāpēc GeoPackage ir priekšroka salīdzinājumā ar Shapefile mobilajām lietotnēm? GeoPackage apvieno ģeometriju, atribūtus un indeksēšanu vienā kompaktā SQLite failā, kas ļauj veikt ātru tiešu rediģēšanu, nepakļaujoties vairāku failu atkarības riskiem, kā tas ir ar Shapefile.

Vai GeoPackage var vienlaicīgi glabāt gan rastra, gan vektoru datus? Jā, OGC GeoPackage standarts atbalsta vektoru elementus un rastra flīžu piramīdas tajā pašā datu bāzes konteinerā.

Kas padara MBTiles par ideālu mobilajām pamata kartēm? MBTiles saglabā desmitiem tūkstošu kartes flīžu indeksētā SQLite datu bāzē, novēršot mobilā failu sistēmas kavēšanos, ko izraisa mapju pārlūkošana atsevišķos attēlu failos.

Kad izstrādātājiem vajadzētu izvairīties no GeoJSON izmantošanas mobilajās lietotnēs? Izvairieties no GeoJSON, ja strādājat ar datu kopām, kas pārsniedz 10 MB vai satur tūkstošiem elementu, jo lielu JSON teksta bloku parsēšana izraisa atmiņas pārspriegumu un mobilās UI kavēšanos.

Kā FlatGeobuf uzlabo mobilo vektoru datu straumēšanu? FlatGeobuf ļauj bināru lasīšanu bez atmiņas deserializācijas un izmanto HTTP diapazona pieprasījumus, lai mobilās ierīces lejupielādētu tikai pašreizējā skatā esošās funkcijas.

Skatīt arī

GIS failu formāti vietnē FileFormat.com

Top 5 GIS failu formāti Google Maps

Failu formātu ziņas

Failu formātu forumi

GeoParquet vs. GeoJSON: Kurš GIS formāts ir labāks lieliem datu kopumiem?

Ja jebkad esat mēģinājis atvērt 2 GB GeoJSON failu QGIS vai ielādēt vairāk nekā miljonu rindu daudzstūru robežas failu interaktīvā kartē, jau zināt, kāda ir noslīdes sajūta – iesaldēts ekrāns un atmiņas pārsnieguma avārija.

Vairāk nekā desmit gadu GeoJSON ir kalpojusi kā universāla pasaules valoda tīmekļa kartogrāfijā. Tā ir caurspīdīga, cilvēkiem lasāma, un ir atbalstīta jau no sākuma gandrīz katras tīmekļa kartēšanas bibliotēkas un REST API internetā.

Tomēr mūsdienu GIS darba plūsmas izskatās radikāli atšķirīgi nekā 2008. gadā. Šodienas ģeotelpiskie praktiķi regulāri apstrādā gigabaitus (vai terabaitus) IoT mobilitātes telemetrijas, valsts mēroga ēku kontūru, satelītu izceltas segmentācijas maskas un augstas frekvences klimata režģus.

Kad tas tiek piemērots datu kopām šādā mērogā, GeoJSON ne tikai palēninās — tas pilnīgi ierobežo datu arhitektūras.

Ienāk GeoParquet, atvērta, standartizēta ģeotelpiskā paplašinājuma uz Apache Parquet, kas tiek izstrādāta Open Geospatial Consortium (OGC) ietvaros.

Šajā visaptverošajā ceļvedī mēs salīdzinām GeoParquet un GeoJSON arhitektūras, glabāšanas efektivitātes, lasīšanas/rakstīšanas caurlaidības, mākoņa gatavības un izstrādātāju ergonomikas ziņā, lai atbildētu uz svarīgu jautājumu: Kuru formātu izvēlēties lieliem datu kopumiem?

1. Struktūrālā arhitektūra: Teksts pret bināro kolonnu

Lai izprastu, kāpēc šie formāti darbojas tik atšķirīgi lielā mērogā, ir jāskata zem virsmas, kā katrs no tiem attēlo koordinātu vērtības un tabulāro metadatu.

+--------------------------------------------------------------+
| Novērtējuma metriks |
| **Datu formāts** |
| **Ģeometrijas attēlojums** |
| **Saspiešanas attiecība** |
| **Kolonnas projekcija** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Telpiskā predikāta pārsūtīšana** |
| **Mākoņa objektu glabātuve (S3/GCS)** |
| **Cilvēka lasāmība** |
| **Tīmekļa pārlūkprogrammu atbalsts** |
| **Standartizācijas institūcija** |
+--------------------------------------------------------------+

GeoJSON: Rindu-orientēts, teksta kodēts JSON

GeoJSON attēlo datus kā JSON objektu masīvu. Katrs vienīgais elements skaidri atkārto atribūtu atslēgas kopā ar virkņu kodētām peldošā komata skaitļu masīvām:

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

Tā kā GeoJSON ir teksta balstīts:

• Atkārtoti shēmas: Lauku nosaukumi, piemēram, "properties", "type" un "coordinates", tiek atkārtoti miljoniem reižu, palielinot neapstrādāta faila izmēru.
• Dārga virknes‑uz‑peldošā komata konversija: Jūsu CPU ir jāparsē teksta rakstzīmes ("-", "9", "7", ".", "7"...) uz 64‑bitu IEEE dubultas precizitātes peldošajiem skaitļiem, pirms veic jebkuru telpisko operāciju.
• Monolītiskas lasīšanas prasības: Standarta JSON parsētājiem jāielādē viss fails atmiņā, lai izveidotu Dokumenta Objektu Modeli (DOM). Vienas atribūta lasīšana prasa parsēt katru vienu elementu.

GeoParquet: Kolonu-orientēti, bināri kodēti dati

GeoParquet balstās tieši uz Apache Parquet, glabājot telpiskās tabulas kolonnu pa kolonnai, nevis rindas pa rindai.

Tādi atribūti kā county tiek glabāti nepārtrauktos blokos, ļaujot izmantot uzlabotas saspiešanas tehnoloģijas, piemēram, garuma kodēšanu (RLE), bitu paketi un vārdnīcas saspiešanu. Ģeometrijas dati tiek standartizēti kā Well-Known Binary (WKB), kam seko iekļauti JSON metadati, kas detalizē telpisko atsauču sistēmu (CRS), robežkastes un ģeometrijas tipus.

Tā kā GeoParquet ir binārs un kolonnu veidots:

• Nulles koordinātu parsēšanas izmaksas: Ģeometrijas tiek glabātas tieši binārā formā, apietot dārgas virknes‑uz‑peldošā‑komata konvertācijas.
• Projekcijas pushdown: Ja jūsu turpmākais darba plūsmas posms vajag tikai county un pop_density kolonnas, lasītājs ielādē tikai šos baitu nobīdes no diska vai S3, pilnīgi izlaidot ģeometrijas kolonnu.
• Rindu grupas sadalīšana: Parquet faili sadala ierakstus pašpietiekamās "Row Groups" (bieži 100 000 līdz 1 000 000 rindu katrā) ar pilnīgiem min/max statistikas datiem katrai kolonnai.

2. Tieša salīdzinājuma pārskats: Galvenie rādītāji

3. Uzglabāšanas efektivitāte un failu izmēru salīdzinājumi

Kad mērogo no tūkstošiem uz miljoniem ierakstu, glabāšanas atšķirības kļūst dramatiski lielākas.

Standarta veiktspējas testos, izmantojot reālus atvērtus telpiskos ierakstus (piemēram, OpenStreetMap ēku kontūras, ASV Skaitīšanas TIGER robežas un globālos kuģu AIS žurnālus), GeoParquet regulāri sasniedz 70 % līdz 85 % glabāšanas samazinājumu salīdzinājumā ar neapstrādāto GeoJSON, un pārspēj .geojson.gz papildu 20 % līdz 40 %.

Kāpēc GeoParquet ir tik daudz mazāks?

1. Dictionary Encoding: Atkārtoti teksta atribūti (piemēram, štatu kodi, zemes izmantošanas klasifikācijas) tiek indeksēti kā mazi veseli skaitļu rādītāji, nevis glabāti atkārtoti kā garas virknes.
2. Compact Binary Coordinates: 2D punkts GeoJSON aizņem apmēram 30 līdz 45 baitus ASCII teksta ([-122.4194155, 37.7749295]). WKB formātā tas pats koordinātu pāris prasa tieši 16 baitus.
3. Modern Compression Algorithms: Zstandard (Zstd) un Snappy saspiež kolonnu baitu masīvus daudz efektīvāk nekā standarta Gzip spēj saspiest pārklāto rindu balstīto tekstu.

4. Vaicājumu veiktspēja un mākoņdatora dzimtie darba plūsmas

Lielāko atšķirību lieliem datu kopumiem nav tikai glabāšana — tas ir vaicājumu latentums un atmiņas izmantošana.

1. Selektīva lasīšana, izmantojot kolonnu projekciju

Iedomājieties 15 GB valsts zemes gabalu datu kopu, kas satur 60 atribūtus (īpašnieku vārdi, nodokļu ID, īpašuma vēsture, zonēšanas kodi un sarežģītas daudzstūru robežas).

• GeoJSON formātā: Ja vēlaties aprēķināt vidējo novērtēto īpašuma vērtību katram pasta indeksam, jūsu analītiskajam dzinējam jālejupielādē un jāparsē visi 15 GB, ieskaitot miljoniem sarežģītu robežvirsotņu.
• GeoParquet formātā: Analītiskie dzinēji, piemēram, DuckDB, Apache Sedona, Polars vai AWS Athena, lasa tikai zip_code un assessed_value kolonnas. Tā vietā, lai pārsūtītu 15 GB, jūsu dzinējs lejupielādē un skenē mazāk nekā 80 MB.

2. HTTP diapazona pieprasījumi mākoņglabā

GeoParquet darbojas nevainojami kā mākoņdatora dzimtā ģeotelpiskā formāts.

Tā kā Parquet faili saglabā iekšējos nobīdes un metadatus savā faila kājenē, klientu bibliotēkas var izsūtīt HTTP GET Range: bytes=... pieprasījumus uz mākoņpakalpojumu krātuvēm, piemēram, Amazon S3, Google Cloud Storage vai Azure Blob Storage. Tā vietā, lai lejupielādētu visu vairāk nekā gigabaitu lielo failu, klients lasa kāju, identificē precīzās baitu nobīdes, kur atrodas attiecīgie ieraksti, un lejupielādē tikai nepieciešamos apakškopumus.

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. Programmatūras ekosistēma un rīku atbalsts

Vēsturiski GeoJSON galvenais priekšrocība bija universāla rīku atbalsts. Lai gan tas joprojām ir patiesi pārlūkprogrammu vidēs, GeoParquet ekosistēma ir strauji attīstījusies:

• Desktop GIS: Dabisks lasīšanas/rakstīšanas atbalsts QGIS 3.28+, ArcGIS Pro un GDAL/OGR 3.5+.
• Analytical Engines & Languages: Ātras vektorizētas lasīšanas/rakstīšanas iespējas Python (GeoPandas, pyarrow), R (sf), DuckDB (caur telpisko paplašinājumu), Apache Sedona un Snowflake.
• Big Data Pipelines: Dabiska integrācija ar Apache Spark, Trino, Presto un Databricks.
• Client-Side Web Maps: Vieglas WebAssembly bibliotēkas (piemēram, parquet-wasm un duckdb-wasm) tagad ļauj tīmekļa pārlūkprogrammām vaicāt GeoParquet failus tieši klienta ierīcēs bez īpaša GIS starpniekservera.

6. Praktiska lēmumu matrica: kad izmantot kādu?

                                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

Izvēlies GeoJSON, ja:

• Jūsu datu kopas lielums ir no 50 MB līdz 100 MB.
• Jūs atgriežat vieglas slodzes atbildes no REST API uz priekšējām klientēm.
• Jūs veidojat vieglas tīmekļa kartes, izmantojot Leaflet, MapLibre vai Mapbox GL JS, bez starpposma tulkošanas slāņiem.
• Jums ir nepieciešama ātra manuāla rediģēšana vai pārbaude standarta koda vai teksta redaktorā.

Izvēlies GeoParquet, ja:

• Jūsu datu kopas apjoms pārsniedz 100 MB vai tā satur simtiem tūkstošu sarežģītu telpisko elementu.
• Jūs glabājat vektoru aktīvus mākoņa objektu glabātuvē (S3, GCS, MinIO, Azure Blob).
• Jūs veicat telpisko SQL analīzi, funkciju izstrādi vai mašīnmācības cauruļvadu, izmantojot Python, DuckDB, Spark vai Databricks.
• Jūs vēlaties samazināt glabāšanas izmaksas, izvairīties no tīkla izvadīšanas maksām un novērst atmiņas avārijas.

7. Migrācijas piemērs: GeoJSON konvertēšana uz GeoParquet

Esošo telpisko aktīvu konvertēšana uz GeoParquet prasa tikai dažas koda rindas.

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

Izmantojot GDAL / OGR (CLI)

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

Lietojot 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. Kopsavilkums: Spriedums par lieliem datu kopumiem

Mazām datu kopām un tiešiem tīmekļa galapunktiem GeoJSON joprojām ir uzticams, bezrūpīgs utilītformāts.

Tomēr, lielām datu kopām GeoParquet ir objektīvi pārāks katrā operacionālajā kategorijā. Tas nodrošina mazākus failu apjomus, ievērojami zemākas glabāšanas pārklas, gandrīz tūlītējus telpiskos nolasījumus un iebūvētu integrāciju ar mūsdienīgiem mākoņa datu noliktavām.

Ja jūsu ģeotelpiskie cauruļvadi raud zem pārāk lielu GeoJSON failu svara, pāreja uz GeoParquet ir viens no visefektīvākajiem infrastruktūras uzlabojumiem, ko varat veikt.

Biežāk uzdotie jautājumi (BUJ)

Q1. Vai GeoParquet ir oficiāli atzīts GIS standarts? Jā, GeoParquet ir oficiāls atvērtais standarts, ko uztur Open Geospatial Consortium (OGC) vadībā.

Q2. Vai es varu tieši attēlot GeoParquet failu tīmekļa kartēšanas bibliotēkās, piemēram, Leaflet vai Mapbox GL JS? Lai gan tas netiek nativi parsēts kā GeoJSON, jūs varat attēlot GeoParquet pārlūkprogrammās, izmantojot WebAssembly pakotnes, piemēram, parquet-wasm, vai pārvēršot failus uz Vektoru flīzēm (PMTiles/MVT) pie uzņemšanas.

Q3. Vai GeoParquet atbalsta vairākas koordinātu atsauces sistēmas (CRS)? Jā, atšķirībā no GeoJSON (kas ir stingri ierobežots uz WGS 84 / EPSG:4326 saskaņā ar RFC 7946), GeoParquet ļauj pielāgotas CRS definīcijas tieši savā iekļautajā faila metadatu.

Q4. Kā GeoParquet salīdzina ar FlatGeobuf lieliem telpiskajiem datu kopumiem? FlatGeobuf ir optimizēts, lai straumētu telpiskās funkcijas tieši uz interaktīvām tīmekļa kartēm, izmantojot R-Tree telpisko indeksēšanu, savukārt GeoParquet ir paredzēts augstas veiktspējas kolonnveida analīzei, kompresijai un milzīgu datu ezeru glabāšanai.

Q5. Vai varu atvērt GeoParquet failus darbvirsmas GIS programmatūrā, piemēram, QGIS? Jā, modernas QGIS versijas (versija 3.28 un jaunākas) atbalsta vilkšanu, nomaišanu, skatīšanu un stilu piemērošanu GeoParquet failiem, neprasot trešo pušu spraudņus.

Skatīt arī

GIS failu formāti vietnē FileFormat.com

Top 5 GIS failu formāti Google Maps

Failu formātu ziņas

Failu formātu forumi