Closed kylebarron closed 9 months ago
Code looks fine for me so far!
geozero has very limited support for empty (null) geometries. See this discussion for more details: https://github.com/georust/geozero/pull/20#discussion_r840003700
For now I switched to prototyping a geoarrow implementation as a crate in geopolars so that I could iterate faster, and in the future I think it would make sense to come back and figure out how to integrate with geozero.
I suppose I could also just implement GeomProcessor
in the geoarrow crate and keep it as a separate implementation, like the flatgeobuf crate is.
Closing this because this was implemented in https://github.com/geoarrow/geoarrow-rs, with bindings from that into geozero
This is a sketch (only point and multipoint are implemented for now) of reading from the proposed struct encoding in the geoarrow spec.
GeoArrow is undecided as of now whether the point object should be represented by a logical "struct" (physically, the x and y arrays are distinct in memory) or a logical "fixed size list" (physically, x and y coordinates are interleaved). This PR implements the struct approach; it's not hard to switch between the two, so we could implement both for now and then remove one if/when the geoarrow spec chooses one for the standard.
Notes:
List<Struct<x: f64, y: f64>>
(i.e. a logical type representing a variable size list of x,y structs) could either represent a multipoint or a linestring, so we need some metadata to describe which it is. Arrow2 has an example here of using extension types. Geoarrow extension type names are defined here.Related to https://github.com/georust/geozero/issues/37