Anthony North

I wonder if it's worth relaxing the `ESPG:4326` constraint, instead being any crs that a coordinate transform from _whatever_ provided to `ESPG:4326` would be a noop? I think we can...

This is a little better, geojson and non-geojson paths are _almost_ the same. ```r coord_trans_filter

[hypertidy/proj](https://github.com/hypertidy/proj) 0.5 will give us a lightweight transformer that works with all geometry formats rdeck supports (https://qfes.github.io/rdeck/reference/wk-geometry.html) and with minimal overhead. I'm thinking auto-coordinate transforms should be an option, which...

Were you thinking that geoarrow/geoparquet would be used only as a storage format? If so, I think it would make sense to restore the geometry format that was defined in...

Arguably yes and by default, given the intended use-case.

I can make a start on this piece if you're taking PRs. Are we implementing a `wk_vctr` or are we taking a dependency on {vctrs} and implementing a `vctrs_vctr`? Should...

I had intended to action this (almost) 2 weeks ago. I am still interested in having a stab at this, but I've been focused on other projects. I haven't implemented...

Should `geoarrow()` replicate the behaviour in paleolimbot/geoarrow, where `geoarrow::geoarrow()` can accept any handleable? This makes `geoarrow()` pretty much an alias of `as_geoarrow()`. Or, should `geoarrow()` instead require a geoarrow array?...

> I think the stricter option is better I agree. A couple of usecases for a `geoarrow()` constructor: - `wk::wk_translate(something, geoarrow())` - `vctrs::vec-_cast(something geoarrow()) # your example above` - Converting...

> Those uses, do make sense...maybe it should be restricted to creating just a zero-size version for the "make me a ptype" use case? Maybe. I don't have a strong...