geopandas
In `GeoDataFrame.to_parquet` rename `geoarrow` keyword argument to `native`
I've had multiple people ask me what the geometry_encoding="geoarrow" keyword does. We're writing to GeoParquet... but this is GeoArrow in GeoParquet? Huh?
I think the term "GeoArrow" is too overloaded, where here it refers to the "geoarrow-like" geometry encoding, rather than the in-memory format. I think it would be clearer to have users refer to the GeoParquet encoding as "native" rather than "geoarrow".
I understand the rationale with wanting to make this change, and appreciate that since you're building tools leveraging geoarrow you're getting more exposure to people using it than I am - I can only speak for me and my experience naming things. Happy to be shot down or for other suggestions.
But I worry that "native" is also prone to mis-interpretation and might lead to confusion with platform native code with an incorrect assumption about the encoding being platform / architecture specific. "native" also doesn't align nicely with the terminology in the geoparquet spec, which refers to the "single-geometry type encodings based on the GeoArrow specification."
I wonder if this would just benefit from improving the existing documentation - with what's already written we don't exactly explain what is meant by encoding - and that sounds like part of the problem from the question you've phrased. Would it be clearer if geometry_encoded also supported recieving the single-geometry type encodings, and we explain that "geoarrow" is a convenience alias to infer the appropriate single-geometry type?
The heading in the GeoParquet spec says "native encodings (based on GeoArrow)".
I think thus it would be clearer to use "native" to emphasize that these geoarrow-like encodings are not exactly geoarrow.
We discussed this during the dev call and are happy with this alias. @kylebarron can you just add a simple test ensuring the alias is covered?
Should we think about a coherent plan for what API we want to expose for users to create native Parquet geometry/geography types? And ensure that this rename doesn't conflict with that goal
Should we think about a coherent plan for what API we want to expose for users to create native Parquet geometry/geography types? And ensure that this rename doesn't conflict with that goal
@jorisvandenbossche you mentioned something during the call some time ago, do you remember what you wanted to do regarding support of native Parquet?