Provide multi dimensional geometry objects in `geo-traits`

[latot]

Hi! actually there is the const generic option, which I think would be nice to use as a base to get N dimensions.

This could mix well with the project, the algorithms for 2 dimensions can also be implemented in their respective use case, and the ones who can be generalized could also be done.

What do you think?

[kylebarron]

There's been a lot of discussion about this before. #797, #1150.

Note that the new geo_traits crate supports Z, M, and ZM dimensions. So we could have an alternate backend that uses const generics to support multiple dimensions of coordinates. But having that as a separate crate would be backwards compatible for anything using geo-types now. And you can write algorithms in terms of the traits that support input from many sources with whatever dimension.

[michaelkirk]

See (#1011 edit: woops, I meant #797, same as above) for some prior discussion. The bar for making a change like this to our most fundamental types would be very high.

[latot]

Thx for the replies.

I has been playing a lot with this concept today, and there is ways to on the same crate do it compatible.

For example, each coord and point basic functions can exists on the basic implement function, while all x/y related access are implemented only for points of two dimensions.

Rust support create specialized functions using the const generics, we can take advantage a lot of it, so all the implemented logic functions could be organized in their respective dimension (actually 2), also helps to extend them on the future.

Agree change the base is very expensive, from the issue seems intentions are of the crate being used for more ppl, is just... z, y, z, m are just a subset of the spatial/geometry use, the lack one 0, 1 and >=3 dimensions hits a lot in what we can do...a lot of data and things are not in two dimensions, a lot of research (including the one I do) also uses different number of dimensions... my point there is that handle and use two dimensions also means restrict ppl who can contribute, in my case for example I would move to write my own crate, which is sad because I was expecting be able to contribute here.

From what I see, Lat/Long/UTM/XY/Z/M, should be above, at base an abstract geometry layer which we can use and over that make that needed functions for that particular cases, that could open how to use the crate.

Thx!

[kylebarron]

I think it would take at least a year to get enough consensus to add support for multiple dimensions to geo-types. I'd encourage you to explore the use of geo-traits to interoperate across the geospatial rust ecosystem without needing changes to geo-types.

[yutannihilation]

So we could have an alternate backend that uses const generics to support multiple dimensions of coordinates.

Are there any plan to provide the default backend (i.e. struct like Point, PointZ and Geometry) in the geo-traits crate? I found geo-traits cool as long as I can just use the provided implementation, but, when it turned out I need some struct for intermediate values, it's a bit overwhelming to implement such structs by myself.

For example, I'm trying to replace geo-types with geo-traits in my code using the shapefile crate.

let geometry = geo_types::Geometry::<f64>::try_from(shape)?;
builders.geo_builder.push_geometry(Some(&geometry))?;

I found this simple case can be handled simply like this thanks to the fact that the shapefile provides GeometryTrait implementations, This is the cool part of geo-traits!

match &shape {
    shapefile::Shape::Point(point) => {
        builders.geo_builder.push_geometry(Some(point))?;
    }
    shapefile::Shape::PointZ(point_z) => {
        builders.geo_builder.push_geometry(Some(point_z))?;
    }
    shapefile::Shape::Polyline(polyline) => {
        builders.geo_builder.push_geometry(Some(polyline))?;
    }
    shapefile::Shape::PolylineZ(polyline_z) => {
        builders.geo_builder.push_geometry(Some(polyline_z))?;
    }
    ...
    _ => return Err(format!("Unsupported shape type: {}", shape.shapetype()).into()),
}

However, when I found I want to transform the coordinates before pushing it the builder, I got stuck. If I understand correctly, I have to implement structs for each geometry type and implement GeometryTrait for it just to hold the intermediate values until they are pushed to the builder. For 2D-types, I can use geo-types' structs, but there are nothing for 3D. I feel it would be great if geo-traits provides such structs in order to supersede the geo-types crate.

[kylebarron]

For 2D-types, I can use geo-types' structs, but there are nothing for 3D.

In geoarrow, I use types defined in wkt for anything more than 2d:
https://docs.rs/wkt/latest/wkt/types/index.html

I agree this is non-obvious and we should have a better solution though

[yutannihilation]

Oh, thanks, good to know! I'll try using it.

I hope the geo-traits crate provides such structs for convenience.

[kylebarron]

Maybe we could behind a feature flag?

[yutannihilation]

Maybe we could behind a feature flag?

Do you mean to simply re-export wkt structs behind a feature flag? Or, implementing a set of structs in geo-traits? I tried the latter one here. I'm not sure if this is useful, but hope this helps us to figure out what things we need to implement.

#1441