Closed kylebarron closed 1 year ago
The other benefit to something like this is generics where you want to return the same geometry type as input. Like
pub fn scale(
array: &GeometryArray, ...
) -> Result<GeometryArray> {}
operates on enums, even when you know that point input returns point output. So then you have to match on the output as well
Or maybe it just makes sense to move away from a functional approach? I.e. have methods off of each array type directly instead of having the operations be pure functions?
Or maybe it makes sense to actually model after geo
. Where geo imports a trait, and that trait gets implemented on a concrete type. So similarly I'd have
use geoarrow::ops::geo::Area;
let array: PolygonArray = ...;
let out: PolygonArray = array.scale(...);
This is achieved by moving to traits, e.g. https://github.com/kylebarron/geoarrow-rs/pull/53, https://github.com/kylebarron/geoarrow-rs/pull/55, https://github.com/kylebarron/geoarrow-rs/pull/56 and related prs around the same time.
So now everything is implemented on each array type (using macros!) and nothing operates on bare geometry arrays. This means both in rust and in JS we have accurate type information on what geometry type an array is.
Right now we have operations like
We then need a verbose
match
on the array type. But when thearea
function is implemented on every geometry type, there should be some way to doThen we wouldn't need a
match
statement with a lot of copying between match arms. The downsides there are:geo::Geometry
I think, not a different geometry type per trait implementation? Or always have to convert the local geometry type intogeo::Geometry
?