Kyle Barron
Kyle Barron
> Specifically, `into_arrow` produces a "minimal" union (only the types actually present in the mixed array) while `ChunkedMixedGeometryArray::data_type` produces a superset union of all possible types. I've provided some test...
> It looks like you have some skeleton code here: I don't think that itself is a relevant part of the code. You're probably hitting union type issues somewhere else....
But can you remind me what line of code that's coming from? It's not in the writer code you linked to
https://github.com/geoarrow/geoarrow-rs/pull/714 that'll be a big PR to work on next week.
@gadomski can you try again from latest main?
The heading in the GeoParquet spec says ["native encodings (based on GeoArrow)"](https://github.com/opengeospatial/geoparquet/blob/68715146415addca99a1819455fe44d60fa49f95/format-specs/geoparquet.md#native-encodings-based-on-geoarrow). I think thus it would be clearer to use "native" to emphasize that these geoarrow-_like_ encodings are not...
Should we think about a coherent plan for what API we want to expose for users to create native Parquet geometry/geography types? And ensure that this rename doesn't conflict with...
For me this seems to work by specifying `manylinux: "2_28"` for the aarch64 build. https://github.com/kylebarron/arro3/pull/277
Thanks, it looks like it does compile with `2_24`, just not with `2_17`.
Or a `stac-geoparquet-data` repo?