Clarity on future of geoarrow parquet writer in light of parquet native geospatial type?

[C-Loftus]

Thank you for the great work you have done on this crate.

Since parquet now supports a native geospatial type, I wanted to get clarity on the future long term goals of the geoparquet writer implementation. Will the geoparquet writer which utilizes geoarrow types eventually be deprecated and one day removed? Or will there be some sort of conversion layer which takes in geoarrow types and abstracts away the logic to convert them into native geospatial types upon file creation?

---

My understanding is that:

• in parquet there is a native geospatial type with an associated writer implementation in Rust here.
• Re this blog post it seems that geoarrow types may be eventually dropped in a future version of the spec in order to unify the type representations.

  • The latest thinking is that we’d do a GeoParquet 2.0, that would just have one geometry type — the Parquet one. We’d drop support for the Arrow geometry type, as having a native geo parquet geometry achieves one of the main goals behind the arrow geometry, which was native stats and not needing the bbox column.

As such, I also wanted to check if there was any guidance for users of this functionality. Should writers be slowly but surely transitioning to the geospatial support directly in arrow-rs?

Regards
Colton

[kylebarron]

I think it depends partially on the resolution of opengeospatial/geoparquet#278

If the GeoParquet community moves to deprecate GeoParquet 1.1 and only support a native type, then perhaps we won't need the geoparquet crate and we can focus on the geospatial support in the parquet crate.

I don't know the current recommendation of the GeoParquet community of whether to be writing 1.1 metadata and native types, or what exactly to suggest. This might be a good discussion thread to put in the GeoParquet repo.