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 theGeoArrow 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?