Aida van de Wetering rebuilds GeoPolars as a geo namespace inside Polars in about 125 commits

The case the dev.to write-up makes for the rebuild is integration. It argues that putting geometry inside Polars removes an external dependency and the overhead of switching between libraries ^[10]. That saving only shows up in a given pipeline if a real share of its runtime goes into moving frames between Polars and GeoPandas. If most of the time goes into the geometry operations themselves, we would not expect a namespace alone to change the total.

The affine transforms show the expression design most clearly. Translate, rotate, scale, skew and arbitrary matrices are all supported, and the matrix can vary per row ^[7]. That makes the transform parameters column data, so one query can move each geometry by its own offset. This is good design, and it is what a geo namespace inside a DataFrame engine should look like.

We'd spend the first afternoon on the CRS work. The prototype keeps CRS metadata and computes distance, length and area according to it. The write-up gives the split between geodesic and planar methods as the example of why that matters ^[5]. A useful first test is one polygon of known area stored twice, once in a geographic CRS and once in a projected one. The two results should agree with each other and with a reference value.

The operations list is short. It names centroid, boundary, interior and coordinate accessors ^[6]. The write-up does not list spatial predicates, spatial joins or buffering. On I/O, WKB and WKT go both ways, and GeoParquet only goes out ^[4]. A pipeline whose inputs arrive as GeoParquet could, going by that list, write its output through GeoPolars and still need another route to read its input.

GeoPolars has gone dormant once already ^[1]. The write-up credits the revival to one contributor ^[2]. It also warns that if the project stalls again, users risk staying locked into GeoPandas ^[11]. Its own guidance is to use GeoPolars once it matures when performance and Polars integration are critical, and to rely on GeoPandas for stability otherwise ^[9]. In our view that is the right split for production. The dev branch is ready for a test against a team's own geometry now, on an API the write-up calls fluid ^[8].