kylebarron commented on issue #7799: URL: https://github.com/apache/arrow-rs/issues/7799#issuecomment-3085067118
Thanks for creating the issue @kaushiksrini! > I am no 100% sure how this is related to geo-arrow / geo-parquet but perhaps it is [GeoParquet](https://github.com/opengeospatial/geoparquet) is a community-driven approach/spec to storing vector geospatial data in Parquet. It uses key-value metadata to describe what column(s) are geospatial, but doesn't modify the format at all; all GeoParquet files are still normal Parquet files. Read/write support for GeoParquet can (and should) be implemented totally external to the `parquet` crate, e.g. in my [`geoparquet` crate](https://docs.rs/geoparquet/latest/geoparquet/). Then after some time the Parquet community decided they were open to creating a native Parquet logical type for geospatial data. This native logical type is the "next version" of GeoParquet so to speak. This logical type actually modifies some structures in the Parquet file, and is what this issue is about, if I understand correctly. GeoArrow is an extension to Arrow to convey logical type information on top of arrow arrays. Ideally the Parquet logical type would read/write some sort of GeoArrow data. Most simply, it would read the binary buffers from Parquet and then just add the `geoarrow.wkb` Arrow extension name. > I’d be happy to have a stab at implementing this—I'll put together a draft and break it into smaller chunks to make the review easier. Great! I'd be happy to review a draft too! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
