Implement conversions to GEOS objects

[kylebarron]

TODO:

• Implement conversions back to geoarrow from arrays of geos objects
• Add tests
• Document minimum GEOS version of 3.10

[kylebarron]

@chrispahm this may interest you! It won't work in webassembly but opens the door to more interactions between the geoarrow format and GEOS

[chrispahm]

That sounds great! Is the idea then to use GeoRust methods if available, and otherwise fall back to GEOS?
And could you explain a little further why this wouldn't work in webassembly?

Edit: is it because you're binding to the native GEOS library to construct the geometries? https://github.com/kylebarron/geoarrow-rs/pull/108/files#diff-d3825c859e07f524352858e0fd96957469e36e056eecd1408a6e9d0b186a8664R36

[kylebarron]

The idea is to let users choose whether to use native georust or GEOS for operations. The GEOS support is behind an optional feature flag so that environments that don't want to/can't include GEOS can work with all the non-GEOS functionality.

And could you explain a little further why this wouldn't work in webassembly?

WebAssembly is a pretty minimal environment, and doesn't include e.g. libc by default. So in the C/C++ world, that's where emscripten comes in, to bridge between C programs and wasm. But Rust doesn't have the baggage of C and can compile to webassembly without needing emscripten. So in Rust there are two different targets for Wasm: wasm32-unknown-unknown and wasm32-unknown-emscripten, where only the latter uses emscripten.

Most of the Rust-wasm world is built on the former, and so the tooling for using rust + emscripten is very underdeveloped. More info in rustwasm/team#291.

So it'll be possible to build to the wasm32-unknown-emscripten target including the optional GEOS support, but it's not a path well-trodden.

[kylebarron]

Notes to self:

• Getting geos_linestring_objects does not live long enough on trying to convert to a MutableLineStringArray.

[kylebarron]

I didn't get the reverse conversion finished but going to merge so that I can prototype/test functions using GEOS that don't return geometries, e.g. area

[chrispahm]

Thanks for the explanation @kylebarron! So essentially, if it would be possible to build to wasm32-unknown-emscripten, it would also include GEOS? So we wouldn't need to import geos-wasm at another point, right?

[kylebarron]

Correct, if we figured out the build tooling for wasm32-unknown-emscripten, then ideally we could have performant FFI between JS and wasm but still use GEOS for the algorithms under the hood. That would be completely independent of geos-wasm