Open kylebarron opened 11 months ago
Both approaches sound good to me but if the into_coord_seq
approach is simpler, please go ahead with this one.
Might still be worth to improve get_coord_seq
in the future though.
Actually thinking about this a little more.. might one way to solve this be to implement a ConstCoordSeq
struct just like there's a ConstGeometry
?
That could work too.
From the docstring of
get_coord_seq
:My use case is to bind GEOS algorithms to the GeoArrow memory layout (an efficient geometry layout for arrays of geometries, see geoarrow.org and my WIP rust implementation at https://github.com/geoarrow/geoarrow-rs). My current plan is to always store geometries before and after each operation in GeoArrow memory, and therefore GEOS objects are totally ephemeral during an operation. So the process goes like
Therefore the IO to and from GEOS objects is really important to me, because it's overhead for every operation on the array.
One option is to improve this
get_coord_seq
, removing a clone. The other possibility for me is to have something likeinto_coord_seq
orinto_inner
. Given that I want to consume the GEOS geometry anyways, and only access its coords, this might be easier to implement?I'd be willing to attempt a PR!