Beste GIS-bestandsformaten voor mobiele applicaties: de definitieve ontwikkelaarsgids

Mobiele GIS-toepassingen worden geconfronteerd met hardware- en netwerkbeperkingen die desktop GIS-installaties nooit tegenkomen. Handheld-apparaten werken met beperkte RAM, wisselende batterijduur en intermitterende of niet-bestaande mobiele connectiviteit op het veld. Het proberen te parseren van een monolithische, slecht gestructureerde ruimtelijke dataset op een iOS- of Android-apparaat leidt tot applicatiecrashes, trage aanraakrespons en ernstige batterijontlading.

Het kiezen van de juiste geografische gegevenscontainer is de meest impactvolle technische beslissing bij het ontwikkelen van veldinspectietools, logistieke dashboards, offline wandeltrackers of stedelijke planningsapplicaties. Deze gids behandelt de belangrijkste ruimtelijke formaten voor mobiele omgevingen, vergelijkt hun operationele afwegingen en biedt bruikbare aanbevelingen op basis van praktijkvoorbeelden.

Technische beperkingen van mobiele GIS-omgevingen

Overweeg, voordat u formaten evalueert, de vier kernbeperkingen die de mobiele prestaties bepalen:

1. Geheugenallocatie (RAM): Mobiele besturingssystemen beëindigen agressief achtergrondprocessen of heap-intensieve taken. Het laden van niet-geïndexeerde vectorlagen direct in het geheugen veroorzaakt een snelle Out-Of-Memory (OOM)-beëindiging.
2. Offline I/O en Willekeurige Toegang: Veldwerkers verliezen vaak netwerktoegang. De opslagengine moet geïndexeerde, schijf-niveau ruimtelijke query’s ondersteunen (bijv. R-Tree) zodat de applicatie alleen de functies leest die zich momenteel in het viewport bevinden in plaats van het hele bestand te scannen.
3. Gegevensoverhead en Bandbreedte: Het verzenden van omvangrijke payloads via 3G/4G/5G-netwerken slurpt de batterijen van apparaten uit en verbruikt dure datalimieten.
4. Lezen/Schrijven Mutabiliteit: Mobiele inspectieworkflows vereisen dat veldpersoneel GPS-coördinaten registreert, notities toevoegt, statusattributen bijwerkt en bewerkingen synchroniseert met centrale databases zonder bestandscorruptie.

Gedetailleerde evaluatie: Top GIS-indelingen voor mobiel

1. GeoPackage (.gpkg) — De onbetwiste industriële gouden standaard

Onderhouden als een open standaard door het Open Geospatial Consortium (OGC), GeoPackage is gebouwd bovenop een ingebedde SQLite-databankcontainer.

• Waarom het uitblinkt op mobiel: SQLite is native ingebed in zowel Android- als iOS-besturingssystemen. Het opvragen van een GeoPackage vereist geen zware aangepaste parseerlaag. Het maakt gebruik van ruimtelijke indexering (R-Tree) direct uit de doos, waardoor applicaties snel ruimtelijke bounding-box segmenten kunnen ophalen zonder de volledige database in RAM te laden.
• Belangrijkste mogelijkheden: Het ondersteunt zowel vectordata als raster-tegelpiramides in één compact binair bestand. Het verwerkt meerdere lagen, complexe attributen, schemadefinities en directe ruimtelijke updates (INSERT, UPDATE, DELETE).
• Het beste te gebruiken voor: Offline gegevensverzameling, veldinspectie‑apps (bijv., QField, Mergin Maps), asset‑beheer en gemengde vector/raster offline opslag.

2. MBTiles (.mbtiles) — Beste voor basiskaarten en rasterbeelden

Oorspronkelijk ontwikkeld door Mapbox, MBTiles is ook een op SQLite gebaseerde specificatie die specifiek is ontworpen om vooraf gerenderde kaarttegels te verpakken.

• Waarom het uitblinkt op mobiel: MBTiles lost het knelpunt van het bestandssysteem op. Het opslaan van tienduizenden individuele tegelafbeeldingen (.png of .pbf) direct op mobiele bestandssystemen vermindert de prestaties. Het verpakken van die tegels in één SQLite‑container maakt bijna onmiddellijke opzoekacties mogelijk via standaard SQL‑tegels coördinatenindexering (z, x, y).
• Vector Tiles (MVT) binnen MBTiles: Wanneer gecombineerd met Mapbox Vector Tiles (MVT), levert MBTiles ultracrispe, high‑performance basiskaarten die dynamisch on‑device kunnen worden hergestyled via GPU‑rendering met een minimale opslagvoetafdruk.
• Het beste te gebruiken voor: Offline basiskaarten, luchtfoto‑basislagen, wandelkaarten en navigatiedisplays.

3. FlatGeobuf (.fgb) — Beste voor hoge-prestatie alleen-lezen vectorstreaming

FlatGeobuf is een modern binair coderingsformaat voor vectorgegevens, gebaseerd op FlatBuffers.

• Waarom het uitblinkt op mobiel: In tegenstelling tot GeoJSON vereist FlatGeobuf geen deserialisatiestap. De CPU leest gegevens rechtstreeks uit de binaire stroom zonder tussenliggende geheugenobjecten toe te wijzen. Het bevat een ingebouwde ruimtelijke index (gepackte Hilbert R-tree). FlatGeobuf is vooral krachtig via HTTP/HTTPS: mobiele clients kunnen HTTP-range‑verzoeken doen om alleen het deel van de vectordata te downloaden dat de huidige viewport van het apparaat dekt.
• Beperkingen: FlatGeobuf is fundamenteel een archief-/streamingformaat; het is niet bedoeld voor bewerken van databases op hun plaats of voor manipulatie van veldrecords.
• Het beste te gebruiken voor: High‑speed streaming van zware vectordatasets (bijv. landelijke percelen, contouren, wegnetwerken) met vrijwel onmiddellijke weergave van de viewport.

4. GeoJSON (.geojson) — Beste voor alleen lichtgewicht API-payloads

GeoJSON is een open, menselijk leesbare standaard gebaseerd op JavaScript Object Notation.

• Waarom het riskant is voor grote datasets: Omdat GeoJSON tekstgebaseerd en niet geïndexeerd is, moeten mobiele apparaten de hele string parseren en elke coördinaat en eigenschap in het geheugen instantiëren voordat ze worden gerenderd. Een GeoJSON‑bestand van 40 MB kan snel uitgroeien tot enkele honderden megabytes heap‑geheugen, waardoor een mobiele client crasht.
• Wanneer te gebruiken: Ideaal voor het verzenden van kleine transactionele payloads (bijv. een enkele routegeometrie, 50 nabijgelegen punten van interesse, of snelle API‑formulierinzendingen).

5. Shapefile (.shp) — Waarom je het op mobiel moet vermijden

Ontwikkeld in de jaren 1990 door Esri, blijft het Shapefile‑formaat gangbaar op legacy‑desktopsystemen, maar het is slecht geschikt voor mobiele ontwikkeling:

• Het vereist meerdere bijbehorende bestanden (.shp, .shx, .dbf, .prj), wat leidt tot risico’s op bestandsynchronisatie en -verpakking.
• Veldnamen worden afgekapt tot 10 tekens.
• De maximale bestandsgrootte is hard beperkt tot 2 GB.
• Het mist moderne coderingsstandaarden, waardoor vaak tekensetcorruptie optreedt bij internationale tekst.

Vergelijkingsmatrix: Mobiele GIS-formaten

Praktische architecturale aanbevelingen

Bij het bouwen van een productieklare mobiele GIS-architectuur, vermijd het vertrouwen op één enkel formaat voor alle taken. Moderne GIS-apps gebruiken een meerlagige opslagbenadering:

1. Voor offline veldbewerkingen & gegevensverzameling: Gebruik GeoPackage (.gpkg). De native SQLite‑basis zorgt voor ACID‑conformiteit, multi‑tabel‑joins, naadloze geometrische updates en betrouwbare offline caching.
2. Voor offline basiskaarten & tegeloverlays: Gebruik MBTiles (.mbtiles) met Mapbox Vector Tiles (MVT). Het houdt de bestandsopslag schoon en ontlast de rendering naar de mobiele GPU.
3. Voor live cloud-naar-mobiel vector synchronisatie: Stream geometrieën met FlatGeobuf (.fgb) via HTTP‑range‑verzoeken voor enorme alleen‑lezen lagen, of lichte GeoJSON‑fragmenten voor individuele puntupdates en realtime waarschuwingen.

SEO-metadata & voorgestelde titels

Titel-tag suggesties

1. Beste GIS-bestandsformaat voor mobiele apps: prestaties, opslag en offline gids
2. Mobiele GIS-architectuur: waarom GeoPackage en MBTiles oudere formaten overtreffen
3. Top GIS-formaten voor mobiele app-ontwikkeling: snelheid, geheugen en offline synchronisatie

Suggesties voor meta-beschrijving

1. Ontdek de beste GIS-bestandsformaten voor mobiele apps. Vergelijk GeoPackage, MBTiles, FlatGeobuf en GeoJSON op geheugen efficiëntie, offline synchronisatie en snelle weergave.
2. Een mobiele mapping‑app bouwen? Ontdek welke ruimtelijke gegevensformaten geheugencrashes voorkomen, offline veldbewerking ondersteunen en razendsnelle weergave garanderen.
3. Een ontwikkelaarsgids voor mobiele GIS‑bestandsformaten. Zie waarom GeoPackage en MBTiles de velddataverzameling domineren terwijl verouderde Shapefiles tekortschieten.

Veelgestelde Vragen

Waarom wordt GeoPackage verkozen boven Shapefile voor mobiele toepassingen? GeoPackage consolideert geometrie, attributen en indexering in één compact SQLite‑bestand, waardoor snelle directe bewerking mogelijk is zonder de risico’s van afhankelijkheid van meerdere bestanden die bij Shapefiles horen.

Kan een GeoPackage zowel raster‑ als vectordata gelijktijdig opslaan? Ja, de OGC GeoPackage‑standaard ondersteunt vectorfeatures en raster‑tegels piramides binnen exact dezelfde databasecontainer.

Wat maakt MBTiles ideaal voor mobiele basiskaarten? MBTiles slaat tienduizenden kaarttegels op in een geïndexeerde SQLite‑database, waardoor vertraging in het mobiele bestandssysteem door directory‑zoekopdrachten naar losse afbeeldingsbestanden wordt geëlimineerd.

Wanneer moeten ontwikkelaars GeoJSON vermijden in mobiele apps? Vermijd GeoJSON bij datasets groter dan 10 MB of duizenden features, omdat het parseren van grote JSON‑tekstblokken hoge geheugenspieken en vertraging in de mobiele UI veroorzaakt.

Hoe verbetert FlatGeobuf het streamen van mobiele vectordata? FlatGeobuf maakt binair lezen zonder geheugen-deserialisatie mogelijk en gebruikt HTTP-rangeverzoeken zodat mobiele apparaten alleen de features in hun huidige viewport downloaden.

Zie ook

GIS-bestandsformaten op FileFormat.com

Top 5 GIS-bestandsformaten voor Google Maps

Nieuws over bestandsformaten

Forums over bestandsformaten

GeoParquet vs. GeoJSON: Welk GIS-formaat is beter voor grote datasets?

Als je ooit hebt geprobeerd een 2 GB GeoJSON‑bestand in QGIS te openen of een polygon‑grensbestand met miljoenen rijen in een interactieve kaart te laden, weet je al dat het gevoel van een bevroren scherm en een out‑of‑memory‑crash.

Al meer dan een decennium dient GeoJSON als de universele lingua franca van webcartografie. Het is transparant, menselijk leesbaar en wordt out‑of‑the‑box ondersteund door bijna elke web‑mappingbibliotheek en REST‑API op internet.

Echter, moderne GIS‑workflows zien er radicaal anders uit dan in 2008. De hedendaagse geospatiale professionals nemen routinematig gigabytes (of terabytes) aan IoT‑mobiliteitstelemetrie, landelijke gebouwcontouren, door satellieten afgeleide segmentatiemaskers en hoogfrequente klimaatrasters op.

Wanneer het wordt toegepast op datasets van deze omvang, vertraagt GeoJSON niet alleen—het vormt een volledige knelpunt in data‑architecturen.

Maak kennis met GeoParquet, een open, gestandaardiseerde geospatiale extensie voor Apache Parquet die zich in incubatie bevindt binnen de Open Geospatial Consortium (OGC).

In deze uitgebreide gids vergelijken we GeoParquet en GeoJSON op het gebied van architectuur, opslag efficiëntie, lees-/schrijfsnelheid, cloud gereedheid en ontwikkelaar ergonomie om een cruciale vraag te beantwoorden: Welk formaat moet je kiezen voor grote datasets?

1. Structurele architectuur: tekst versus binaire kolomindeling

Om te begrijpen waarom deze formaten zo verschillend presteren op schaal, moet je onder de motorkap kijken naar hoe elk coördinaatwaarden en tabelmetadata weergeeft.

+--------------------------------------------------------------+
| Evaluatiemetric |
| **Gegevensformaat** |
| **Geometrische representatie** |
| **Compressieverhouding** |
| **Kolomprojectie** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Ruimtelijke predicaat pushdown** |
| **Cloud Object Storage (S3/GCS)** |
| **Menselijke leesbaarheid** |
| **Webbrowserondersteuning** |
| **Standaardiseringsorgaan** |
+--------------------------------------------------------------+

GeoJSON: rijgeoriënteerd, tekstgecodeerde JSON

GeoJSON stelt gegevens voor als een array van JSON-objecten. Elke afzonderlijke feature herhaalt expliciet attribuutsleutels naast een array van als tekst gecodeerde zwevende-kommagetallen:

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

Omdat GeoJSON tekstgebaseerd is:

• Repetitieve schema’s: Veldnamen zoals "properties", "type" en "coordinates" worden miljoenen keren herhaald, waardoor de ruwe bestandsgrootte toeneemt.
• Kostenintense teken-naar-float conversie: Je CPU moet teksttekens ("-", "9", "7", ".", "7"...) omzetten naar 64-bit IEEE double-precision floats voordat een ruimtelijke bewerking kan worden uitgevoerd.
• Monolithische leesvereisten: Standaard JSON-parsers moeten het volledige bestand in het geheugen laden om het Document Object Model (DOM) op te bouwen. Het lezen van één attribuut vereist het parseren van elke afzonderlijke feature.

GeoParquet: kolomgeoriënteerd, binair gecodeerde gegevens

GeoParquet bouwt direct voort op Apache Parquet, waarbij ruimtelijke tabellen kolom-voor-kolom worden opgeslagen in plaats van rij-voor-rij.

Attributen zoals county worden opgeslagen in aaneengesloten blokken, waardoor geavanceerde compressietechnieken mogelijk zijn, zoals run-length encoding (RLE), bit-packing en dictionary-compressie. Geometriegegevens zijn gestandaardiseerd als Well-Known Binary (WKB), vergezeld van ingebedde JSON-metadata die ruimtelijke referentiesystemen (CRS), begrenzingskaders en geometrietypen beschrijft.

Omdat GeoParquet binair en kolomgebaseerd is:

• Geen Kosten voor Coördinaatontleding: Geometrieën worden direct in binaire vorm opgeslagen, waardoor dure string-naar-float conversies worden omzeild.
• Projection Pushdown: Als je downstream workflow alleen de kolommen county en pop_density nodig heeft, haalt de lezer alleen die byte-offsets op van schijf of S3, en slaat de geometrie‑kolom volledig over.
• Row-Group Partitionering: Parquet‑bestanden splitsen records in zelfstandige “Row Groups” (vaak 100.000 tot 1.000.000 rijen per groep) met volledige min/max‑statistieken voor elke kolom.

2. Directe vergelijking: de kernmetriek

3. Opslagefficiëntie en benchmarks voor bestandsgrootte

Wanneer je opschaalt van duizenden naar miljoenen records, worden de opslagverschillen dramatisch groter.

In standaard benchmarks met echte open ruimtelijke records (zoals OpenStreetMap gebouwcontouren, US Census TIGER grenzen, en wereldwijde scheeps AIS-logs), behaalt GeoParquet consequent 70% tot 85% opslagreducties vergeleken met ruwe GeoJSON, en verslaat .geojson.gz met nog eens 20% tot 40%.

Waarom is GeoParquet zoveel kleiner?

1. Dictionary Encoding: Herhaalde tekenreeksattributen (bijv. staatscodes, landgebruikclassificaties) worden geïndexeerd naar kleine integer‑pointers in plaats van herhaaldelijk als lange tekenreeksen op te slaan.
2. Compact Binary Coordinates: Een 2D‑punt in GeoJSON neemt ongeveer 30 tot 45 bytes ASCII‑tekst in beslag ([-122.4194155, 37.7749295]). In WKB vereist datzelfde coördinaatpaar exact 16 bytes.
3. Modern Compression Algorithms: Zstandard (Zstd) en Snappy comprimeren kolom‑byte‑arrays veel effectiever dan standaard Gzip interleaved rij‑gebaseerde tekst kan comprimeren.

4. Queryprestaties en cloud‑native workflows

De grootste onderscheidende factor voor grote datasets is niet alleen opslag—het is querylatentie en geheugengebruik.

1. Selectieve lecties via kolomprojectie

Stel je een nationale perceeldataset van 15 GB voor met 60 attributen (eigenaarsnamen, belasting‑ID’s, eigendomsgeschiedenis, bestemmingscodes en complexe multipolygon‑grenzen).

• In GeoJSON: Als je de gemiddelde getaxeerde vastgoedwaarde per postcode wilt berekenen, moet je analytische engine alle 15 GB downloaden en parseren, inclusief miljoenen complexe grens‑vertices.
• In GeoParquet: Analytische engines zoals DuckDB, Apache Sedona, Polars of AWS Athena lezen alleen de zip_code en assessed_value kolommen. In plaats van 15 GB over te dragen, downloadt en scant je engine minder dan 80 MB.

2. HTTP-bereikverzoeken op cloudopslag

GeoParquet werkt naadloos als een cloud-native geospatiaal formaat.

Omdat Parquet‑bestanden interne offsets en metadata in hun bestandsfooter opslaan, kunnen client‑bibliotheken HTTP GET Range: bytes=...‑verzoeken sturen naar cloud‑objectstores zoals Amazon S3, Google Cloud Storage of Azure Blob Storage. In plaats van een heel multi‑gigabyte bestand te downloaden, leest de client de footer, identificeert de exacte byte‑offsets waar relevante records zich bevinden, en downloadt alleen de benodigde subsets.

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. Software-ecosysteem & toolondersteuning

Historisch gezien was het belangrijkste voordeel van GeoJSON de universele toolondersteuning. Terwijl dat nog steeds geldt voor browseromgevingen, is het ecosysteem van GeoParquet snel volwassen geworden:

• Desktop GIS: Native ondersteuning voor lezen/schrijven in QGIS 3.28+, ArcGIS Pro en GDAL/OGR 3.5+.
• Analytische engines & talen: Snelle gevectoriseerde lees-/schrijfmogelijkheden in Python (GeoPandas, pyarrow), R (sf), DuckDB (via de spatial extensie), Apache Sedona en Snowflake.
• Big Data-pijplijnen: Native integratie met Apache Spark, Trino, Presto en Databricks.
• Client-side webkaarten: Lichtgewicht WebAssembly-bibliotheken (zoals parquet-wasm en duckdb-wasm) stellen webbrowsers nu in staat om GeoParquet-bestanden direct op clientapparaten te raadplegen zonder een dedicated GIS-middleware server.

6. Praktische beslissingsmatrix: wanneer welke te gebruiken?

                                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

Kies GeoJSON als:

• Uw dataset is kleiner dan 50 MB tot 100 MB.
• U retourneert lichte payload-responses van een REST API naar frontend-clients.
• U bouwt lichte webkaarten met Leaflet, MapLibre of Mapbox GL JS zonder tussenliggende vertaallagen.
• U heeft snelle handmatige bewerking of inspectie nodig in een standaard code- of teksteditor.

Kies GeoParquet als:

• Uw dataset overschrijdt 100 MB, of bevat honderden duizenden complexe ruimtelijke kenmerken.
• U slaat vectorassets op in cloudobjectopslag (S3, GCS, MinIO, Azure Blob).
• U voert ruimtelijke SQL‑analyse, feature‑engineering of machine‑learning‑pijplijnen uit met Python, DuckDB, Spark of Databricks.
• U wilt opslagkosten verlagen, netwerkkosten voor uitgaand verkeer vermijden en geheugencrashes elimineren.

7. Migratievoorbeeld: GeoJSON naar GeoParquet converteren

Het converteren van bestaande ruimtelijke assets naar GeoParquet vereist slechts een paar regels code.

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

Gebruik GDAL / OGR (CLI)

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

DuckDB gebruiken

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. Samenvatting: Het oordeel over grote datasets

Voor kleine datasets en directe web‑endpoints blijft GeoJSON een betrouwbaar, probleemloos utiliteitsformaat.

Echter, voor grote datasets is GeoParquet objectief superieur in elke operationele categorie. Het levert kleinere bestandsafdrukken, aanzienlijk lagere opslagoverhead, bijna‑directe ruimtelijke leesbewerkingen, en native integratie met moderne cloud‑datawarehouses.

Als uw geospatiale pipelines kreunen onder het gewicht van te grote GeoJSON-bestanden, is overschakelen naar GeoParquet een van de meest effectieve infrastructuurupgrades die u kunt uitvoeren.

Veelgestelde vragen (FAQ)

Q1. Is GeoParquet een officieel erkende GIS-standaard? Ja, GeoParquet is een officiële open standaard die wordt onderhouden onder de leiding van de Open Geospatial Consortium (OGC).

Q2. Kan ik een GeoParquet-bestand direct weergeven in web‑mappingbibliotheken zoals Leaflet of Mapbox GL JS? Hoewel het niet native wordt geparseerd zoals GeoJSON, kunt u GeoParquet in browsers weergeven met WebAssembly‑pakketten zoals parquet-wasm of door bestanden bij het inladen te converteren naar Vector Tiles (PMTiles/MVT).

Q3. Ondersteunt GeoParquet meerdere coördinatenreferentiesystemen (CRS)? Ja, in tegenstelling tot GeoJSON (dat strikt beperkt is tot WGS 84 / EPSG:4326 volgens RFC 7946), staat GeoParquet aangepaste CRS-definities toe direct binnen de ingebedde bestandsmetadata.

Q4. Hoe verhoudt GeoParquet zich tot FlatGeobuf voor grote ruimtelijke datasets? FlatGeobuf is geoptimaliseerd voor het streamen van ruimtelijke features direct naar interactieve webkaarten met behulp van R-Tree ruimtelijke indexering, terwijl GeoParquet is ontworpen voor high-performance kolomanalyses, compressie en massale data lake opslag.

Q5. Kan ik GeoParquet-bestanden openen in desktop GIS-software zoals QGIS? Ja, moderne versies van QGIS (versie 3.28 en hoger) ondersteunen het slepen, neerzetten, bekijken en stylen van GeoParquet-bestanden zonder dat derden plugins nodig zijn.

Zie ook

GIS-bestandsformaten op FileFormat.com

Top 5 GIS-bestandsformaten voor Google Maps

Nieuws over bestandsformaten

Forums over bestandsformaten