Introduce trait for accessing geometries

[pka]

In the course of refactoring rust-postgis to use rust-geo geometries, I'm looking at needed conversions between different georust geometries. One goal would be to store a rust-gdal geometry with rust-postgis as efficient as possible.

One possible solution would be using iterators returning a Point trait instead of accessing the structs directly. If rust-gdal would implement this trait, storing a geometry with rust-postgis could be done without any conversion. And if the geo algorithms would use this trait, they could be applied directly on geometries implementing this trait. It should also solve the ownership problem in #21.

A simplified trait could be

pub trait PointType {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
    //...
}

When this trait is implemented for geo::Point and geo::LineString implements IntoIterator with Item=&PointType, you can iterate like

let xsum = linestring.into_iter().fold(0., |sum, p| sum + p.x());

[frewsxcv]

Sorry, didn't see this until today. I'll need a day or two to think this through but I think this is a good idea. I'm not sure how this might work for something like LineStringType. I'll try you respond again tomorrow after I've played around with this idea.

[pka]

My current experiments look like this:

pub trait PointType {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
    //...
}

pub trait LineStringType<'a> {
    fn points(self) -> PointRefIter<'a>;
}

pub trait MultiLineStringType<'a> {
    fn lines(self) -> LineStringRefIter<'a>;
}

I got the point iterator working, but not yet the line iterator.

let sumx = linestring.points().fold(0., |sum, p| sum + p.x());

[frewsxcv]

I played around with this idea today: https://is.gd/tqkzBp

I think this is a good idea. If you have any feedback for my link above, let me know. Commented out section was something I tried, but I couldn't get the typechecker to behave. Will have to do some more thinking.

[pka]

I made some progress implementing the following traits:

pub trait Point {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
    //...
}

/// Iterator for points of a line
pub struct Points<'a, T: 'a + Point>
{
    pub iter: Iter<'a, T>
}

pub trait LineString<'a> {
    type PointType: Point;

    fn points(&'a self) -> Points<'a, Self::PointType>;
}

/// Iterator for lines of multi-lines
pub struct LineStrings<'a, T: 'a + LineString<'a>>
{
    pub iter: Iter<'a, T>
}

pub trait MultiLineString<'a> {
    type LineStringType: LineString<'a>;

    fn lines(self) -> LineStrings<'a, Self::LineStringType>;
}

Full code is here

[pka]

Nicer traits which don't depend on std::slice::Iter

pub trait Point {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
    //...
}

/// Iterator for points of line or multi-point geometry
pub trait Points<'a> {
    type ItemType: 'a + Point;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

pub trait LineString<'a>: Points<'a> {
}

/// Iterator for lines of multi-lines
pub trait Lines<'a> {
    type ItemType: 'a + LineString<'a>;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn lines(&'a self) -> Self::Iter;
}

pub trait MultiLineString<'a>: Lines<'a> {
}

Full code on playground

[frewsxcv]

@pka I really appreciate the effort you're putting into this! ✨ In my opinion, I do think this is the right path for rust-geo; supplying a set of traits like these matches Rust's principle of "abstraction without overhead".

Even though I am interested in helping out with this, I'm writing just to inform that I probably won't be able to make assist in any progress with this specific issue over the next couple weeks (busy week with work and preparing a workshop for a conference). Just thought I'd mention instead of just leaving you hanging.

[pka]

I've ended up with the following traits:

pub trait Point {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
    fn opt_z(&self) -> Option<f64> {
        None
    }
    fn opt_m(&self) -> Option<f64> {
        None
    }
}

pub trait LineString<'a> {
    type ItemType: 'a + Point;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

pub trait Polygon<'a> {
    type ItemType: 'a + LineString<'a>;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn rings(&'a self) -> Self::Iter;
}

pub trait MultiPoint<'a> {
    type ItemType: 'a + Point;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

pub trait MultiLineString<'a> {
    type ItemType: 'a + LineString<'a>;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn lines(&'a self) -> Self::Iter;
}

pub trait MultiPolygon<'a> {
    type ItemType: 'a + Polygon<'a>;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn polygons(&'a self) -> Self::Iter;
}

They are implemented in rust-postgis allowing to store any geometry type implementing these traits.

[jdroenner]

I really like the idea of having traits for accessing geometries :)
Is it really necessary to have opt_m and opt_z ? And will they always be f64? As Point is a trait could this be handled by generics?

[pka]

Hi @jdroenner

• With XYZM attributes the OGC SF standard is covered. In rust-postgis opt_m and opt_z are needed to store e.g. 3D points in the DB
• My point in concentrating on f64 was simplicity. If you want to implement algorithms like an intersection, you have to solve the numerical problems only for one numeric type. You can still implement the trait for f32 or even i32 points (e.g. screen coordinates like in MB vector tiles), but all operations are done with f64.
  It was difficult enough (at least for me) to find traits which are implementable for rust-postgis and rust-gdal, so I didn't try to make them generic.

[jdroenner]

Hi @pka
i understand that it is not easy to find a generic trait which fits all needs. Maybe we could split the Point into multiple traits? Something like this:

pub trait Point2D {
    fn x(&self) -> f64;
    fn y(&self) -> f64;
}

pub trait Point3D : Point2D {
    fn z(&self) -> Option<f64> {
        None
    }
}

pub trait Measurement<M> {
    fn m(&self) -> Option<M> {
        None
    }
}

pub trait LineString<'a> {
    type ItemType: 'a + Point2D;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

This still allows to have XYZM Points in rust-postgis e.g. pub trait PointXYZM: Point3D + Measurement<f64> {} but is more explicit. One would know what kind of Point to expect...
Maybe this could also be usefull to implement algorithms for 2D and 3D cases.

[pka]

Looks nice for points, but I don't see how you could access Z values of 3D line points and I'm afraid that I had to write separate WKB conversion routines for each point type.

[jdroenner]

I guess you are right. If we treat Point2D and Point3D as different types than some things have to be handled separate.

Accessing the z values of 3D line points shouldn't be a problem. If you have something like this:

impl Point2D for (f64, f64, f64) {
    fn x(&self) -> f64 {
        self.0
    }
    fn y(&self) -> f64 {
        self.1
    }
}

impl Point3D for (f64, f64, f64) {
    fn z(&self) -> Option<f64> {
        Some(self.2)
    }
}

impl <'a, T> LineString<'a> for Vec<T> where T: 'a + Point2D {
    type ItemType = T;
    type Iter = std::slice::Iter<'a, Self::ItemType>;
    fn points(&'a self) -> Self::Iter {
        self.iter()
    }
}

A line could be created like this: let line = vec!((1.0, 2.0, 3.0), (4.0, 5.0, 6.0));. This allows to use the entries as Point3D and provides access to the Z values.

[pka]

I'm with you, that these traits are implementable for 3D point types. But wouldn't we need additional line traits like

pub trait LineString3D<'a> {
    type ItemType: 'a + Point3D;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

for accessing Z values?
In your LineString implementation ItemType has type Point2D, so the compiler won't let us call line.points().last().unwrap().z()
Don't get me wrong. I'm all for more elegant traits, but I'm still sceptical whether there is a practical implementation.

[jdroenner]

We can use the associated type ItemType of the LineString trait to define the type of the points:

pub trait LineString<'a> {
    type ItemType: 'a + Point2D;
    type Iter: Iterator<Item=&'a Self::ItemType>;
    fn points(&'a self) -> Self::Iter;
}

pub fn do_something<'a, L>(line: &'a L)  -> f64 where L: LineString<'a>, L::ItemType: Point3D {
    line.points().last().unwrap().z().unwrap()
}