Implementing ST_length as a UDF for datafusion

[notreallystatic]

Can I pick this feature @kylebarron? Also, do we just return the Euclidean length in this case?

[kylebarron]

Yes, you're welcome to implement this!

For now, we only support planar geometries (i.e. the postgis Geometry type), so yes, ST_Length refers to the euclidean length here.

Try modeling st_length after the other existing UDFs. Ideally we'll have a core implementation in geoarrow-geo and then a wrapper on top in geodatafusion. If you want to start small, feel free to make a PR just with the geoarrow-geo changes, and then after we merge that we can move to geodatafusion.

[notreallystatic]

Thanks for the info @kylebarron.

I will start with the implementation in geoarrow-geo and will then add a wrapper in geodatafusion. I am thinking that the function would return the length for the geometry-types LineString and MultiLineString, for others it would return 0. Let me know your thoughts.

[kylebarron]

Yes, that sounds great. I agree with returning 0 since that matches the documentation of ST_Length

For areal geometries 0 is returned; use ST_Perimeter instead

You'll additionally need to check the individual geometries yielded from a GeometryArray, WkbArray, etc. Similar to the current implementation of simplify

geoarrow-rs/rust/geoarrow-geo/src/simplify.rs

Lines 46 to 54 in e5444c7

	fn simplify_geometry(geom: &geo::Geometry, epsilon: &f64) -> geo::Geometry {
	match geom {
	geo::Geometry::LineString(g) => geo::Geometry::LineString(g.simplify(epsilon)),
	geo::Geometry::Polygon(g) => geo::Geometry::Polygon(g.simplify(epsilon)),
	geo::Geometry::MultiLineString(g) => geo::Geometry::MultiLineString(g.simplify(epsilon)),
	geo::Geometry::MultiPolygon(g) => geo::Geometry::MultiPolygon(g.simplify(epsilon)),
	_ => panic!("Unsupported geometry type for simplification: {geom:?}"),
	}
	}

[notreallystatic]

Hey @kylebarron, I have a query related to casting. My idea is to make a function length which accepts an array: &dyn GeoArrowArray. I would then check the data_type of this array and cast it to the required type. Now, this is straightforward for the LinestringArray and MultiLinestringArray, but to do this typecast for Wkb Array type to LinestringArray/MultiLinestringArray, I would need to know the dimensions beforehand. However, I can't pass this in the function signature. So, I could only think of checking this for all the dimensions(XY, XYM, XYZ, XYMZ) and see which one fails and which one succeeds. Is there any alternative way to do this?

[notreallystatic]

I found that there's a method called wkt::infer_type which could be used here. What are your suggestions?

[kylebarron]

It's a good question.

There are two types of arrays: "primitive"/"native" arrays, where we know in advance that all geometries of the array have the same type and dimension, like a PointArray or MultiLineStringArray. Then there's the GeometryArray, WktArray and WkbArray. These don't have a known geometry type and dimension in advance.

For the second type, we don't want to cast a WkbArray to a LineStringArray; instead we just want to iterate over each geometry, convert it to geo with geometry_to_geo, and then compute the length of each one.

This is why above I linked you to the implementation of simplify

You'll additionally need to check the individual geometries yielded from a GeometryArray, WkbArray, etc. Similar to the current implementation of simplify

geoarrow-rs/rust/geoarrow-geo/src/simplify.rs

Lines 46 to 54 in e5444c7

	fn simplify_geometry(geom: &geo::Geometry, epsilon: &f64) -> geo::Geometry {
	match geom {
	geo::Geometry::LineString(g) => geo::Geometry::LineString(g.simplify(epsilon)),
	geo::Geometry::Polygon(g) => geo::Geometry::Polygon(g.simplify(epsilon)),
	geo::Geometry::MultiLineString(g) => geo::Geometry::MultiLineString(g.simplify(epsilon)),
	geo::Geometry::MultiPolygon(g) => geo::Geometry::MultiPolygon(g.simplify(epsilon)),
	_ => panic!("Unsupported geometry type for simplification: {geom:?}"),
	}
	}

Simplify is a little different in that it's returning geometries instead of a computed numeric value.

Feel free to start the PR with what you can do and we can discuss from there

[kylebarron]

You can also look at the work in #1307

[notreallystatic]

Thanks for the detailed response @kylebarron. Here's the PR, #1308.