Benoit Bovy

> I'd like to avoid going along the same path of including everything some ppl may want in the GeoArrow spec. That is a valid concern, though (not only here...

> Would it help organizing the geoarrow specs into clear categories? That would certainly not help versioning. Separate specs would probably be more reasonable after all... Maybe using `geoarrow-` as...

> I'm not sure squishing all of those into the same concept was a great idea because it's not clear exactly which options are relevant to each function. > Wrapping...

Yes I also generally prefer separate keyword arguments over option classes. I'm not too worried about how to manage a lot of repeated kwargs at the C++ level. Although it...

Since `**kwargs` can be typed with `Unpack[TypedDict]` I wonder if autocompletion would work using a static-checker based lsp server...

Ah yes I forgot about `s2geography::GeographyIndex`, which is exactly what we need. It would also be nice of `s2geography::GeographyIndex` could provide a high-level query API (e.g., by predicate or distance),...

Opened https://github.com/paleolimbot/s2geography/issues/45 as it probably makes more sense to continue the discussion about `s2geography::GeographyIndex` there.

I've been looking into this and opened https://github.com/paleolimbot/s2geography/issues/56 as I think that the easiest way to support `__geo_interface__` (as well as coordinate getters like in #23) is via a customizable...

Agreed a `planar` global option might be dangerous. We could still expose a narrow-scoped option like `geo_interface_planar=True` to work around the impossibility to specify such option as export argument in...

[bigquery's documentation](https://cloud.google.com/bigquery/docs/geospatial-data#coordinate_systems_and_edges) mentions that for loading GeoJSON it uses something similar to `planar=True` and `tessellate_tolerance=10.0`. I haven't seen anything yet about exporting to GeoJSON, but I guess we could use...