Kyle Barron

For reference, in geoarrow-rs we plan to use the `wkt` crate directly for reading/writing WKT instead of using the geozero wrapper. See https://github.com/geoarrow/geoarrow-rs/issues/790, https://github.com/geoarrow/geoarrow-rs/issues/762

> With &str as input, it's straight forward. I'm content with making this an API that uses `&str` for simplicity of implementation. > A `(GeometryType, Dimensions)` tuple might be more...

> I think that sounds really promising. I’d prefer not to lose support for integer geometries though. I wonder if there’s a way to accommodate both? I'm not exactly sure...

That would essentially remove the blanket implementation and implement on the raw number types instead?

Empty points are _stored_ in GeoArrow as `Point(NaN NaN)`. I think this issue is just about how they _render_ in display output, where that would be clearer to display as...

Hmm, perhaps I should assume that input is always EPSG and assign the CRS as such. Then I would have: - `{"crs_type": "authority_code", "crs": "EPSG:4326"}` I _believe_ currently I'm creating...

> Yes You're saying yes that is invalid? In the spec or in your implementation, or both? Is there some spec text we can change to clarify this? > I...

Ok, thanks! That's good info. I'm still trying to ascertain if there's any bug here in `geoarrow-types`. ```py crs.create("4326") # StringCrs(4326) crs.create(4326) # ValueError: Can't create geoarrow.types.Crs from 4326 ```...

Hmm https://github.com/datafusion-contrib/datafusion-geo/blob/171bdaf31069efe618371249e051e5b8eaa109d1/rust/geodatafusion/src/udf/native/constructors/point.rs#L80-L81 https://github.com/geoarrow/geoarrow-rs/blob/338a08cd2f5f2b35df36453ec3ad6ef031dfb702/rust/geoarrow-schema/src/crs.rs#L101-L107 I sure thought I was saving it as a string. This **crashes the interpreter** when trying to access the table schema. (Run with `uv run script.py`) ```py...

This is happening just with `geoarrow-types`, where `geoarrow-c` isn't even a dependency I don't think?