What Is GeoParquet?
GeoParquet defines how geometry and geospatial metadata are stored in Apache Parquet so large vector datasets can use efficient columnar analytical workflows.
Explain GeoParquet's relationship to Parquet, geometry encodings, CRS metadata, columnar strengths, and boundaries with web-delivery formats.
What Is GeoParquet?
GeoParquet is a specification for storing geospatial vector data in Apache Parquet, a columnar file format designed for efficient analytical reading and compression.
Parquet already knows how to store typed tabular columns efficiently; GeoParquet adds conventions for geometry columns and geospatial metadata so software can identify the primary geometry, geometry encoding, coordinate reference system, geometry types, bounding information, and related spatial semantics.
The current stable GeoParquet specification is version 1.1.0; the project also publishes newer release-candidate work separately.
Why columnar storage matters
Row-oriented formats tend to store each feature's full record together, whereas columnar formats group values by column.
That layout is useful for analytics because a query that needs only three fields can often avoid reading dozens of unrelated columns. Similar values also compress efficiently, and engines can use Parquet metadata and row-group statistics to skip data that cannot match a filter.
For a dataset containing tens of millions of features and many attributes, those properties can make a substantial difference to scan performance and storage efficiency.
GeoParquet adds spatial meaning to Parquet
A plain Parquet file can store binary geometry values, but another application would not automatically know which column contains the geometry or how to interpret it.
GeoParquet requires a geo metadata object that identifies information such as:
specification version;
primary geometry column;
geometry encoding;
geometry types;
coordinate reference system;
optional bounding box;
optional coordinate epoch;
optional covering metadata for spatial filtering.
This shared metadata is what turns a convention into an interoperable geospatial format rather than an application-specific Parquet table with a mysterious binary column.
Geometry can use WKB or native encodings
GeoParquet 1.1 allows geometry columns encoded as Well-Known Binary (WKB) or supported single-geometry native encodings based on GeoArrow layouts.
WKB remains a strong portability choice because many geospatial libraries already understand it, while native encodings can expose coordinate values more directly to columnar processing and statistics.
Implementations still vary, so format support should be tested against the tools in the intended workflow rather than inferred only from the specification.
CRS behaviour is explicit
GeoParquet stores CRS metadata using PROJJSON when a CRS is provided.
A subtle but important rule is that omitting the crs field is not the same as setting it to null. Under the 1.1 specification, an omitted CRS means the default is OGC:CRS84—longitude, latitude on WGS 84. An explicit null indicates that the CRS is unknown or undefined.
That distinction helps preserve whether geographic interpretation is known rather than collapsing “not written” and “not known” into the same state.
GeoParquet is strongest for analytics, not direct browser rendering
GeoParquet is well suited to:
large vector datasets;
analytical engines that understand Parquet;
cloud/object-storage workflows;
reading selected columns rather than whole records;
partitioned data lakes;
Python, SQL, and Arrow-based analytics.
It is not usually the format you hand directly to a browser map renderer; instead, a web application may query GeoParquet server-side or transform selected results into GeoJSON or vector tiles for delivery.
That is why GeoParquet vs GeoJSON is less about declaring a winner and more about separating analytical storage from lightweight feature exchange.
The extension does not guarantee spatial indexing by itself
Columnar metadata can help readers skip row groups or files, especially when data are spatially sorted or bounding columns are available. Even so, a GeoParquet file is not automatically equivalent to a spatial database with a dynamic R-tree or GiST index.
Performance depends on how the data are organised, partitioned, sorted, and queried, plus what capabilities the reader implements.
References
GeoParquet 1.1.0 Specification. Defines geometry encodings, geospatial metadata, CRS behaviour, and optional covering metadata for the stable 1.1 release.
GeoParquet Releases. Distinguishes the current stable specification from release-candidate work.
Related content
GeoParquet vs GeoJSON — analytical storage versus lightweight exchange
What Is a GeoPackage? — portable SQLite container
What Information Can Be Lost When Converting GIS Formats? — check schema and metadata before migration