Struct diesel_mysql_spatial::data_types::LineString

source · [−]

pub struct LineString {
    pub srid: SRID,
    pub geom: LineString<f64>,
}

Expand description

A linearly interpolated path between locations.

MySQL extension: The spatial reference system identifier (SRID) may identify the used coordinate system.

Fields

srid: SRIDgeom: LineString<f64>

Methods from Deref<Target = LineString<f64>>

source

pub fn points_iter(&self) -> PointsIter<'_, T>

👎 Deprecated:

Use points() instead

Return an iterator yielding the coordinates of a LineString as Points

source

pub fn points(&self) -> PointsIter<'_, T>

Return an iterator yielding the coordinates of a LineString as Points

source

pub fn coords(&self) -> impl Iterator<Item = &Coordinate<T>>

Return an iterator yielding the members of a LineString as Coordinates

source

pub fn coords_mut(&mut self) -> impl Iterator<Item = &mut Coordinate<T>>

Return an iterator yielding the coordinates of a LineString as mutable Coordinates

source

pub fn lines(&self) -> impl ExactSizeIterator + Iterator<Item = Line<T>>

Return an iterator yielding one Line for each line segment in the LineString.

Examples

use geo_types::{coord, Line, LineString};

let mut coords = vec![(0., 0.), (5., 0.), (7., 9.)];
let line_string: LineString<f32> = coords.into_iter().collect();

let mut lines = line_string.lines();
assert_eq!(
    Some(Line::new(
        coord! { x: 0., y: 0. },
        coord! { x: 5., y: 0. }
    )),
    lines.next()
);
assert_eq!(
    Some(Line::new(
        coord! { x: 5., y: 0. },
        coord! { x: 7., y: 9. }
    )),
    lines.next()
);
assert!(lines.next().is_none());

source

pub fn triangles(&self) -> impl ExactSizeIterator + Iterator<Item = Triangle<T>>

An iterator which yields the coordinates of a LineString as Triangles

source

pub fn close(&mut self)

Close the LineString. Specifically, if the LineString has at least one Coordinate, and the value of the first Coordinate does not equal the value of the last Coordinate, then a new Coordinate is added to the end with the value of the first Coordinate.

source

pub fn num_coords(&self) -> usize

👎 Deprecated:

Use geo::algorithm::coords_iter::CoordsIter::coords_count instead

Return the number of coordinates in the LineString.

Examples

use geo_types::LineString;

let mut coords = vec![(0., 0.), (5., 0.), (7., 9.)];
let line_string: LineString<f32> = coords.into_iter().collect();

assert_eq!(3, line_string.num_coords());

source

pub fn is_closed(&self) -> bool

Checks if the linestring is closed; i.e. it is either empty or, the first and last points are the same.

Examples

use geo_types::LineString;

let mut coords = vec![(0., 0.), (5., 0.), (0., 0.)];
let line_string: LineString<f32> = coords.into_iter().collect();
assert!(line_string.is_closed());

Note that we diverge from some libraries (JTS et al), which have a LinearRing type, separate from LineString. Those libraries treat an empty LinearRing as closed by definition, while treating an empty LineString as open. Since we don’t have a separate LinearRing type, and use a LineString in its place, we adopt the JTS LinearRing is_closed behavior in all places: that is, we consider an empty LineString as closed.

This is expected when used in the context of a Polygon.exterior and elsewhere; And there seems to be no reason to maintain the separate behavior for LineStrings used in non-LinearRing contexts.