Kyle Barron

Closed in https://github.com/geoarrow/geoarrow-rs/pull/650

> I don't think `geoarrow-rs` needs to do the whole thing Yeah this was going to be a point of discussion. The goal for now is implementing as general operations...

Awesome! Let me know if I can help provide pointers or anything

Note: we need a thread-safe variant for Proj (and probably also will need for GEOS)

👋 Hi @ibesora , thanks for chiming in > towards a single package approach but not being able to have tree shaking sounds like a big issue Yes... but that's...

Thanks for chiming in @H-Plus-Time! This has been on my mind recently, and I really don't have any conclusions, so any suggestions are welcomed. I think the core problem is...

> I wonder about this - am I right in figuring that going from an ArrowTable to a GeoTable (or vice versa) would be relatively low-cost? that'll always be O(1)....

I think it's probably fine for geoparquet-wasm to return the same general arrow-wasm object as parquet wasm. As long as it contains the extension metadata you'll still be able to...

hmm looks like I have some issues with the union handling :/

This is superseded by https://github.com/geoarrow/geoarrow-rs/pull/678, which fixes the problem _at hand_, ensuring that empty array metadata is not serialized. It leaves for #679 the problem of deduplicating extension field construction