Kyle Barron

Moving to 0.14 because at least now we parallelize the Parquet serialization across threads (ref https://github.com/developmentseed/lonboard/pull/902)

Thanks for the PR! Since originally implementing the `Take` here, I learned about the upstream [`take`](https://docs.rs/arrow/latest/arrow/compute/fn.take.html), which is doing basically the same thing as we do here. I'm happy to...

I'd be happy to wholesale refactor the `take` implementation to use upstream's `take`, or to remove it altogether I think the main reason why I originally wanted to have a...

I think it's best to point users who want `Take` to use the upstream arrow-rs implementation directly. I don't think it's worth the complexity to implement it in geoarrow-rs as...

Yes, this would be great! I think the simplest approach would be to generate the covering column when writing the files, as then we can be sure that the designated...

fwiw I'm doing some Parquet prototyping for general non-geo files in https://github.com/kylebarron/arro3/pull/313, and then hopefully using some learnings from that to decide on the right API for GeoParquet here.

I hope the refactor has been easy to follow so far. I think the refactor is unequivocally positive in making a simpler, more robust library. I'm at a conference this...

In #1089 I merged a refactor of reading GeoParquet and now we can consider better APIs for writing GeoParquet

https://github.com/geoarrow/geoarrow-rs/pull/1214 refactors the write side

> it seems like we'd probably need a method that takes in a user's `RecordBatch` and some options, and it returns a record batch and metadata that are encoded and...