GeoParquet: putting points, lines and polygons into Apache Parquet

A storage convention, not a piece of software

The GeoParquet repository defines a specification for how to store geospatial vector data, points, lines and polygons, in Apache Parquet, a popular columnar storage format for tabular data.

The stated goal is to further standardize how geospatial data is represented in Parquet, to enhance geospatial interoperability among tools using Parquet today, and to push forward what is possible with cloud-native geospatial workflows. The adoption number is given in the same paragraph: there are now more than 20 different tools and libraries in 7 different languages that support GeoParquet.

That is the whole proposition, and it is worth stating plainly because it is easy to misread a repository like this as a library. There is no package to install and no API to call. There is a document, a JSON schema, examples, and a set of rules that a writer follows so that a reader in another language can make sense of the file.

The contributors listed are the reason the format has credibility, and they come from the projects that would have to implement it: developers from GeoPandas, GeoTrellis, OpenLayers, Vis.gl, Voltron Data, Microsoft, CARTO, and Planet and Unfolded. Each of those has an existing user base that needs to read the same file, and a format written by the people who write the readers tends to have fewer awkward gaps.

The project is an OGC official Standards Working Group and is on the path to becoming an OGC standard. The related GeoArrow specification embraces geospatial in Arrow in a compatible way, and this specification focuses solely on Parquet, with the two developed in parallel so that Parquet is the on-disk persistence format behind Arrow.

Version 2.0, and the path to an OGC standard

The release process is spelled out in the README, and it has a rule that matters for anyone storing data long term.

The latest stable specification and its JSON schema are published on the project site rather than only in the repository. The community has agreed on this release, but it is still pending OGC approval, and the project is working on getting it officially approved as soon as possible by the OGC membership.

The rule is this: released versions of GeoParquet will not be changed. If changes are needed for OGC approval, it will be released with a new version number. So the 2.0.0 specification is a fixed document, and a future 2.0.1 or 3.0.0 is a new document, and a file written against 2.0.0 keeps its meaning.

That is the opposite of how a lot of format specifications evolve, and it is a deliberate choice with a practical consequence for a data catalogue. You can state which version of GeoParquet a file conforms to and know that the statement will stay true.

The dev version of the specification lives in the repository, in a format specs directory, with the specification document, the JSON schema and an examples folder. The README points at the published stable version for actual use and labels the in-repository copy as the dev version, not stable.

The 2.0 release is also the one that changed the foundation. The latest version is 2.0.0, which is based on the Parquet Geospatial Logical Types, and the Parquet format itself now includes core geometry and geography types, with GeoParquet 2 providing guidance for geospatial tools working with those types plus some optional metadata not covered by the core Parquet specification.

Validating what you produce, with two different tools

The validation section is short and it points at two independent implementations, which is the point.

There are two tools that validate the metadata and the actual data, and the recommendation is to use one of them to ensure any GeoParquet you produce, or are given, is completely valid according to the specification.

The first is GPQ, from Planet Labs, and the validate command generates a report.

gpq validate example.parquet

The second is the GDAL and OGR validation script, which is a Python script that can check compliance.

python3 validate_geoparquet.py --check-data my_geo.parquet

Note the difference in the flags. The GDAL script is invoked with a check for the data, and the two tools are maintained by different organisations with different codebases. That is the pattern you want in a validation story: two independent implementations, because a single validator only proves that the file agrees with one opinion of the specification.

The repository holds test data alongside the specification and the examples, and a pre-commit configuration, which is how a document like this stays consistent with the files it describes. The examples directory contains a Parquet file, a CSV version, an R example, and two metadata JSON files, one of them the point variant, which is a useful set of artefacts because they show the same data expressed in the forms a reader might encounter.

The goals, and the warehouse interoperability case

The goals section gives four reasons for the format existing, and the third is the one that matters most in practice.

The first is to establish a great geospatial format for workflows that excel with columnar data. The argument is that most data science and business intelligence workflows have been moving toward columnar data, but current geospatial formats cannot be as efficiently loaded as other data, so the aim is to bring geospatial data best practices to one of the most popular formats.

The second is the mirror image, to introduce columnar data formats to the geospatial world, since most of that world is not yet benefiting from the breakthroughs in data analysis in the broader IT world.

The third is the interoperability one. BigQuery, Snowflake, Redshift and others all support spatial operations, but importing and exporting data with existing formats can be problematic. They all support and often recommend Parquet, so defining a solid GeoParquet helps interoperability.

That is the argument that changed the conversation. The problem with a file format that only geospatial tools read is that the moment you want to do analysis on it, you export it to something else and the data is now in two places. If the warehouse can read the file directly, the export step disappears.

The fourth goal is to persist geospatial data from Apache Arrow, with GeoParquet developed in parallel with the GeoArrow spec, so that cross-language in-memory analytics of geospatial information works with Arrow, with Parquet already well supported by Arrow as the key on-disk persistence format.

What the format does well, and the case it does not suit

The features section is a quick overview of what GeoParquet supports, or at least plans to support, and the honest caveat comes afterwards.

Multiple spatial reference systems are supported, because many tools will use GeoParquet for high-performance analysis, so it is important to be able to use data in its native projection. But a clear default recommendation is provided, to better enable interoperability, giving implementations that do not want to worry about projections a target to aim at.

There is a default geometry column, but additional geometry columns can be included. Compression is a Parquet property, so data benefits from taking less disk space and being more efficient over the network. Both planar and spherical coordinates are supported, since most cloud data warehouses support spherical ones, and the format aims to be clear about what is supported in each case.

Read-heavy analytic workflows are the target use, because columnar formats make reading a subset of columns cheap, and Parquet in particular enables efficient filtering of chunks based on column statistics. Data partitioning is supported, with the aim of enabling geospatial partitions on top of Parquet's own ability to partition data into different files.

Then comes the caveat, and it is stated plainly rather than buried. GeoParquet is not a good choice for write-heavy interactions. A row-based format will work much better if it is backing a system that is constantly updating the data and adding new data.

That is the trade in one sentence. Columnar storage wins on read performance and compression and loses on frequent mutation, and the specification is honest that it is on the wrong side of that trade for an operational database.

Versioning, the ecosystem and how to try it

The versioning rule is short. As of version 1.0 the specification follows Semantic Versioning, so from that point any breaking change requires the spec to go to the next major version number, for example from 1.0.0 to 2.0.0.

The release history shows that in practice. There is 2.0.0-rc.1 from July 2026, and before that 1.1.0 with a patch suffix in June 2024 and 1.1.0 itself a couple of days earlier. The long gap between 1.1.0 and 2.0.0 is the time it took to move onto the Parquet geospatial logical types, and the release candidate is the community agreeing on the text before the standardisation process finished.

For a reader, the entry points are the published specification and schema on the project site, the implementations list that the README points to for the full set of tools and sample data, and the examples folder in the repository for files that follow the current spec.

The last push to the repository was on 2026-09-21, and the licence is Apache-2.0.

The practical route to trying it is short: take one of the example files, validate it with the GPQ command or the GDAL script, and then read it with whichever of the twenty or so tools you already use. If the file validates and your tool reads it without complaint, the format is doing what it is supposed to do, and the next question is whether your data is read-heavy enough for the trade to be worth making.

Editorial conclusion

Adopt GeoParquet if your spatial data is written once and analysed often, especially if it already lands in a warehouse that can query Parquet, because the format is designed for exactly that reading pattern and the validation tooling makes it checkable. Do not adopt it for a live system that constantly updates geometry, since the specification is explicit that a row-based format serves that case much better. Before you publish a file, run one of the two validators over it, because two independent implementations exist and either one checks both the metadata and the data.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opengeospatial/geoparquet on GitHub
3. Project website
4. README
5. Releases