ENH: Geoparquet types support

[m-richards]

This library is already pretty neat, I can see me using it quite a lot, thanks! I thought though it would be could if the structure and data preview screens could detect geoparquet columns. For example https://github.com/opengeospatial/geoparquet/blob/main/examples/example.parquet

This shows as a BYTE_ARRAY which isn't wrong, but it is a specific kind of byte array, with corresponding geo metadata

I'm familiar with interacting with geoparquet files via geopandas, but geoarrow-pyarrow is probably the natural fit here given this is built on pyarrow (I've just naively looked at the pyproject.toml to infer that, not looked at any of the code).

Perhaps this could be something that is conditionally triggered if geoarrow-pyarrow is installed?

(I haven't checked what happens with datanomy trying to view a parquet file with the new parquet native geometry type)

[raulcd]

hey, thanks for using the tool and thanks for the feedback! This is a great info! I will try to investigate how to better integrate with geoparquet information. I'll possibly have to ask @paleolimbot and @jorisvandenbossche for pointers on the best way of integrating with geoparquet.

It seems the parquet native geometry type is detected correctly as Logical Type Geometry(crs=).

Even though the data visualization is quite unuseful as it currently is:

I've just tested with: https://github.com/apache/parquet-testing/blob/master/data/geospatial/geospatial.parquet

[paleolimbot]

From a purely "parquet structure" point of view, the representation of GeoParquet (i.e., the geo from the key/value metadata) is probably the best way to visualize what is going on with the file. It really is just a regular Parquet file with some metadata.

The Geometry logical type in Parquet is also accurately represented (but is something different). I am not sure if it would be more or less confusing to render geometry elements WKT or not (geoarrow.pyarrow.format_wkt() could do this for you).