geo::algorithm::intersects does not work properly for coordinate to line.

[mndmnky]

I stumbled onto a bug where a coordinate that lays on a line is not considered to intersect that line.

Reproduction:

use geo::{Line, Coordinate};
use geo::algorithm::intersects::Intersects;

let line = Line::new(
    Coordinate{x:0.5, y:1.0},
    Coordinate{x:1.0, y:3.5},
);
let coord = Coordinate{ x:0.9, y:3.0};
assert!(coord.intersects(&line));
assert!(line.intersects(&coord));

[michaelkirk]

Hi @TiBehr.

I think what you're seeing here is an artifact of binary floating point math. For what it's worth, I see similar results from the popular JTS and PostGIS projects:

sql> SELECT ST_Intersects('POINT(0.9 3.0)'::geometry, 'LINESTRING (0.5 1.0, 1.0 3.5)'::geometry);
 st_intersects 
---------------
 f
(1 row)

You get a more intuitive result if you are inspecting points that are not truncated by their floating point representation:

sql> SELECT ST_Intersects('POINT(9 30)'::geometry, 'LINESTRING (5 10, 10 35)'::geometry);
 st_intersects 
---------------
 t
(1 row)

As for what to do about floating point errors, I think the solution depends on the context.

One approach might be for you to determine what your error tolerance is and use some kind of distance calculation instead.

In this particular example you would get the, admittedly unintuitive, result:

assert!(!line.intersects(&coord));
assert_eq!(0.0, line.euclidean_distance(&coord));

Similarly, another way to make the intersection a bit "sloppier", would be to add some buffer to the geometries - making the line a rather thin rectangle, and intersecting with that. However, geo doesn't currently support buffering geometries, but I imagine we'd all like to eventually, but it's not a small task. See #414 for a related issue.

[mndmnky]

Good to know, thanks. That actually helps a lot.

[michaelkirk]

I don't think there's anything specific to do, so closing this issue.