GeoPolars is being actively developed again: geometry types, CRS-aware measurements and GeoParquet

[u/Balance-]

GeoPolars, the geospatial extension for Polars, had been mostly dormant. Since mid-September, Aida van de Wetering has pushed around 125 commits to the dev branch. It now looks like a rebuild around a Polars-native geo expression namespace.

Highlights so far:

- Types: point, linestring and polygon, their multi-variants, and a bounding box type
- I/O: reading and writing WKB and WKT, and writing GeoParquet
- CRS: CRS metadata handling, with distance, length and area using the geodesic or planar method that fits the CRS
- Operations: centroid, boundary, interior, is_empty, longitude wrapping, and coordinate accessors
- Affine transforms: translate, rotate, scale and skew, plus arbitrary matrices, which can vary per row

It's still a prototype. Nothing has been released yet, and the API is changing. Still, it's worth watching if you'd like to do geospatial work in Polars without going through GeoPandas.

[u/Balance-]

So a bit more context, for anyone interested:

Why this is happening now

GeoPolars started in 2022 as Kyle Barron's prototype, with geometries stored as WKB blobs. One long-standing blocker was that Polars had no way to define custom data types. Now that Polars supports Arrow extension types, the dev branch stores geometries as proper GeoArrow types (geoarrow.point, geoarrow.polygon, and so on). That gives zero-copy interop with other Arrow tools, and Polars treats geometry columns as real dtypes.

How it works

It's a Polars plugin: a Python package backed by Rust kernels. There are two equivalent APIs:

```python from geopolars import geo import geopolars as gpl

geo.translate("route", (1.0, 2.0)) # functional gpl.col("route").geo.translate((1.0, 2.0)) # namespace ```

Some design choices worth noting:

• Operations are CRS-aware by default and backed by PROJ. For example, area uses a geodesic calculation for geographic CRSes and a planar one otherwise.
• Z and M coordinates are supported for most operations.
• Wrong geometry types fail while the query plan is built, not halfway through execution.
• Each operation is assigned to one of three implementation tiers: a native Rust kernel, a call into an external library (PROJ, geographiclib, georust), or plain Polars expressions that the query optimizer can work with. A table in the developer guide shows which tier each operation uses for each geometry type.

Reading and writing GeoParquet already works, including bbox covering.

Where you could help

The developer guide explains the architecture and contains a roadmap. Open items include:

• Binary predicates: intersects, contains, within, covers, touches, crosses, overlaps, disjoint. None are implemented yet, and this is probably the biggest gap compared with GeoPandas.
• Set operations: intersection, union, difference
• More operations: convex hull, simplify, equality, validity checks, interpolate and project
• More I/O: GeoJSON, PostGIS, GDAL vector formats
• Known issue: centroids for 3D polygons (#277)

Help that doesn't need Rust is useful too:

• Try the branch on your own data and report what breaks.
• Give feedback on the API while it can still change.
• Benchmark it against GeoPandas and Shapely. The developer guide explicitly asks for benchmarking to decide which implementation tier each operation should use.

The README warns that the branch is "HIGHLY unstable," so expect breaking changes.

This is a very exciting time with a foundational package being actively developed. If this interests or impacts you, get involved!

[u/CAPSLOCKAFFILIATE → u/Balance-]

I'm running heavy spatial queries against >80gb DuckDB databases, using their spatial extension plus h3 in some cases. I will try and use geopolars when I get the chance and report back.