feat(rust/sedona-functions): Implement ST_Force2D() and ST_Force3D()

[yutannihilation]

Part of #554

This pull request enhances CrsTransform to change the number or types of dimensions by introducing these two changes

• transform_coord_3d() takes the dimension of the input coordinate because otherwise there's no way to distinguish if the z value of coord is from the original input or is filled.
  • I think transform_coord() doesn't need this, but I'm not fully sure
• new output_dim() returns the dimension of the output

pub trait CrsTransform: std::fmt::Debug {
    // same
    fn transform_coord(...) -> Result<(), SedonaGeometryError>;

    fn transform_coord_3d(
        &self,
        coord: &mut (f64, f64, f64),
        input_dims: Dimensions, // new
    ) -> Result<(), SedonaGeometryError>;

    // new
    fn output_dim(&self) -> Option<Dimensions>;
}

This pull request implements only ST_Force2D() and ST_Force3D(). In order to implement the variants related to M dimension, ST_Force3DM and ST_Force4D, probably CrsTransform needs to provide more methods that handles M dimension. But, probably these will be used only by ST_Force3DM and ST_Force4D, and I'm not sure if it's worth making the trait complex.

[paleolimbot]

Thank you! A few optional suggestions but also this is a huge improvement over the current situation as is.

and I'm not sure if it's worth making the trait complex.

I think it is, although feel free to file a follow-up ticket to track support of M values in transforms. M values are not heavily used although we (and PostGIS) have generally tried hard to make sure that we don't implement logic that can never extend to XYM geometries. We will probably have to make the trait more complex at some point anyway because the current version I don't think is all that performant in the context of huge arrays of coordinates.

[paleolimbot]

Should a POINT M work here?

[paleolimbot]

Should POINT M work here?

[paleolimbot]

Should POINT M work here?

[yutannihilation]

I see, then I'll address the M dimension variants in another pull request.

feel free to file a follow-up ticket to track support of M values in transforms.

This pull request doesn't close #554, so I don't think another ticket is needed :)

[paleolimbot]

Thank you!

[GalaxyA123]

#606 (comment)