Docs: Does polars-st support multiple geometry columns?

[DeflateAwning]

Supporting multiple geometry columns would be a huge bragging point for this library.

GeoPandas doesn't support multiple geometry columns very well. For example, their .dissolve method (which does a groupby) assumes there's only one geometry column (which is a huge pain, for obvious reasons). It automatically assumes you're talking about "the only geometry column" in a lot of methods, leading to bad assumptions.

Seems that this library could have (and probably does have) first-class support for multiple geometry columns, so bragging about that in the docs (maybe in a "Coming from GeoPandas" section) would be huge!

[oreilles]

The thing is... The GeoPandas concept of a geometry column doesn't really exist in this library. It seems like it, because there is a global configuration with a default geometry column name, but that's all.

So yes, you can have as many geometry columns as you want and work on them in parallel, because they're actually just regular polars binary columns. For example you could "dissolve" (which really is just an union aggregation) several at once by writing:

gdf.group_by("category").agg(st.union_all("geom_1", "geom_2", "geom_3", ...))

[DeflateAwning]

Well that's awesome to hear!

I guess I almost wish that the default geometry column behaviour in queries/transforms didn't exist, as I feel that it creates a bit of a confusing situation where the example code is resorting to implicit behaviours.

I think the default geometry column name behaviour on DataFrame construction might be okay and could make sense, but I'm havin trouble getting behind it in examples like this:

area = gdf.select(st.area())

In normal Polars, there really isn't this same concept. There's pl.all().sum(), for example, which relies on a column selector to apply to all columns individually. And there's pl.col('col_name').sum(), which is explicit on a column. There are certain operations like pl.len() that are column-agnostic. But there's no "do the operation on the "default column" in normal Polars. I think avoiding these sorts of quirks between Polars and Polars-ST is best.

[oreilles]

This is because most of the time, people only deal with dataframes with a single geometry column, which will always have the same name. That's why the concept a default geometry column exists and has been adopted by GeoPandas (at which point it's basically the de-facto standard). The most common operations should be the easiest to write.

If you only every deal with a single column, which is always named "geometry", it can feel very redundant having to write every single time:

area = gdf.select(st.area("geometry"))

instead of :

area = gdf.select(st.area())

At least, that's how it felt to me, especially considering you just have to write area = gdf.area in GeoPandas.
If you don't feel like hiding it away, you can just type the column name manually... But that's not something I'll remove from this library.

[DeflateAwning]

Okay, well fair enough. I guess just the original docs request is where I'll leave this then.

[oreilles]

So I've actually been thinking about this a bit more, and might end up changing my mind. Just so you know. 👍

[DeflateAwning]

Any more thought given to this? I maintain my point that geometry columns should be an additional column type supported with this awesome library, but should NOT fundamentally change the nature of Polars paradigms (namely, that no column is inherently special).

[Makiv1]

This is because most of the time, people only deal with dataframes with a single geometry column, which will always have the same name. That's why the concept a default geometry column exists and has been adopted by GeoPandas (at which point it's basically the de-facto standard). The most common operations should be the easiest to write.

If you only every deal with a single column, which is always named "geometry", it can feel very redundant having to write every single time:

area = gdf.select(st.area("geometry"))
instead of :

area = gdf.select(st.area())
At least, that's how it felt to me, especially considering you just have to write area = gdf.area in GeoPandas. If you don't feel like hiding it away, you can just type the column name manually... But that's not something I'll remove from this library.

Heya, hope your having a lovely day :)

I think allowing statements like

area = gdf.select(st.area())

would be better described as a quirk rather than a feature of polars-st. What are we we getting the area of? It requires the reader to know about this default behaviour in order to accurately interpret what this line of code is doing.

area = gdf.select(st.area("geometry"))

or even more explicitly

area = gdf.select(
    st.area(pl.col("geometry"))
)

Tells the reader exactly what is happening, and requires no knowledge about polars-st to interpret what is happening (for someone who has used polars)

I guess what happens if I don't name my geometry column geometry? What if it's called geom or land_geometry or convex_hull? what does

area = gdf.select(st.area())

return? a ColumnNotFoundError? Having this default column behaviour seems like a footgun to me.

This is a super sick project by the way, thanks for doing this! Would love to help if you're open to it!