GeoParquet vs GeoJSON

GeoParquet and GeoJSON both represent vector geospatial data, but they optimise for different environments.

GeoParquet builds on Apache Parquet's compressed, typed, columnar storage for analytical workloads. GeoJSON represents Features and geometries as human-readable JSON and integrates naturally with web APIs and browser mapping libraries.

A useful rule of thumb is:

use GeoJSON when a modest feature payload needs to be exchanged or rendered simply;
use GeoParquet when large tabular/vector data need efficient analytical storage and selective reading.

Text versus columnar binary storage

GeoJSON repeats object keys, coordinate syntax, and properties as text. That makes it easy to inspect and generate but relatively verbose.

GeoParquet, by contrast, stores columns in a binary columnar representation with compression and typed schema information. Analytical engines can therefore read only the required columns and may skip row groups using metadata rather than parsing every feature.

For small datasets, the simplicity of GeoJSON often matters more than these efficiencies. For millions of records or wide schemas, the balance can reverse.

Browser support strongly favours GeoJSON

Many web mapping libraries can consume GeoJSON directly, allowing JavaScript applications to manipulate the parsed objects without an additional geospatial file reader.

GeoParquet generally needs a specialised reader or a server/data-processing layer before map rendering. Browser-side Parquet tooling exists, but a conventional web map is still much more likely to expect GeoJSON or vector tiles.

This is why GeoParquet is often a source or analytical format, while GeoJSON is a delivery format for selected features.

CRS rules differ

RFC 7946 GeoJSON uses WGS 84 longitude/latitude coordinates in CRS84 ordering and does not provide the old arbitrary-CRS mechanism used by pre-RFC GeoJSON variants.

GeoParquet can record other coordinate reference systems in PROJJSON. Under the stable 1.1 specification, omission of the CRS field implies OGC:CRS84, while explicit null means unknown/undefined CRS.

That makes GeoParquet more expressive for analytical data that genuinely need a projected or specialised CRS.

Schema and data types are richer in GeoParquet

GeoJSON properties are ordinary JSON values, an approach that is flexible but less strict about tabular schema.

Parquet has explicit column types and is designed for data-processing engines. That is advantageous for timestamps, numeric types, booleans, nested values, and large tables where schema stability matters.

Conversion can still be lossy if the target tool does not support the full source schema or if geometry/CRS semantics are simplified.

GeoJSON is easier to debug by eye

Human readability is a practical strength.

When an API returns ten features, opening the GeoJSON and reading the coordinates and properties can be useful. At gigabyte scale, however, that becomes much less meaningful, and a binary columnar file with a query engine is more appropriate.

The right format therefore depends partly on whether the file itself is meant to be a human-inspectable interchange artefact or an efficient analytical dataset.

Large web maps often need neither raw option

Serving a 2 GB GeoJSON file directly to a browser is usually a poor delivery strategy, but serving a 2 GB GeoParquet file directly to the same renderer may not solve the interaction problem either.

At that scale, a common architecture is:

preserve or analyse data in GeoParquet or a spatial database;
query/filter/simplify for the publication;
deliver small GeoJSON responses or vector tiles to the browser.

Why Large GeoJSON Files Make Web Maps Slow explains the browser-side bottleneck.

Choose by workload

Choose GeoJSON for:

lightweight API responses;
small or moderate web-map layers;
simple interchange with JavaScript applications;
easy human inspection.

Choose GeoParquet for:

large analytical vector tables;
column-selective queries;
compressed cloud/object storage;
Arrow/Parquet-oriented processing stacks;
workflows where richer schema and CRS metadata matter.

Using both in one system is often more sensible than forcing either format to serve every stage.

References

RFC 7946 — The GeoJSON Format. Defines modern GeoJSON and its coordinate conventions.
GeoParquet 1.1.0 Specification. Defines stable GeoParquet geometry encodings and metadata.