[EPIC] [Parquet] Implement Geometry and Geography type support in Parquet

[kylebarron]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Parquet recently adopted Geometry and Geography types: apache/parquet-format@master/Geospatial.md

Details on

• PARQUET-2471: Add GEOMETRY and GEOGRAPHY logical types #240

Describe the solution you'd like

I would like to implement geometry and geography support in parquet-rs

Additional context

This has been implemented in Arrow C++ and pyarrow as of v21.0.0 with GH-45522: [Parquet][C++] Parquet GEOMETRY and GEOGRAPHY logical type implementations arrow#45459 change.

Task list

(Each of these can be created as a separate issue for more discussion)

• [Geospatial] Create new parquet-geometry crate #8374
• [Geospatial]: Add CI checks for parquet-geospatial crate #8377
• Add geospatial statistics creation support for GEOMETRY/GEOGRAPHY Parquet logical types #8411
• Added geometry logical types (printing, serialization, deserialization)
• Added geometry column statistics (serialization, deserialization, writing)
• Added [Feature] geometry and geography logical type implementations #7799
• Support reading/writing parquet files containing geometry columns
• Integration test with pyarrow?

Feel free to suggest more tasks or create new issues and I'll update the task list

[alamb]

I think the end user experience is that if you want to use geometry in parquet, it will be done by enabling a geometry feature flag in the parquet crate.

Thus, downstream users can actively enable the additional code / compile time if they need geometry support but if they do not enable the feature flag they will not pay the compile time or binary size cost for that support

The code will follow the same basic structure as the variant implementation -- all the code will live in sub crates (like parquet-geometry) etc

Thank you for filing this @kylebarron -- it is going to be a great feature

[alamb]

I was working on a blog post for arrow 57 and I wonder if this issue is complete (or do we still have more work planned for types)

• Website: Add blog post for arrow-rs 57.0.0 arrow-site#720

[kylebarron]

I think there are significant strides in arrow 57 that unblock use cases, but more work planned to make it really work out of the box. I haven't had the bandwidth, sadly, to truly drive this, but I know @paleolimbot has a good mental model of the end goal here (feel free to edit the list of tasks in the OP)

[paleolimbot]

The remaining one is basically wiring up the Arrow reader and writer!

[alamb]

The remaining one is basically wiring up the Arrow reader and writer!

I filed a ticket to track this work (though I am not sure I have it entirely correct)

• [geometry] Wire up arrow reader/writer for GEOMETRY and GEOGRAPHY #8717

[paleolimbot]

Can we mark this as complete now that #8943 is merged?

[aheev]

Can we mark this as complete now that #8943 is merged?

Also, updating the README

[alamb]

Sounds great -- perhaps someone can make a PR to update the readme and mark it as closing this ticket?

[paleolimbot]

I added a PR to update that README ( #9124 ). If there are more specific follow-up tasks perhaps they could be filed as separate issues?