STIntersection result is STIntersects = 0

It boils down to general approach that you should use when dealing with floating-point numbers in calculations. You should not use equality comparison with floating point numbers, like if a == b, but always compare them with some epsilon precision that makes sense in your application domain, like if abs(a-b) < 1e-8.

It is conceptually similar to performing some non-trivial calculations, for example:

double a = 2.0;
a = sqrt(a);
a = a*a;

and then expecting that if a == 2.0 would return true instead of writing if abs(a-2.0) < 1e-8.


Geometry point in SQL Server is represented as floating point numbers, which are not exact.

DECLARE @intersectionPoint geometry = @a.STIntersection(@b)

calculates intersection point to the best of its precision, but it will never be exact.

So, expression like @b.STIntersects(@intersectionPoint) is conceptually equivalent to equality comparison. It is equivalent to if @b.STDistance(@intersectionPoint) == 0, which will be true only in few special cases.

You should use something like @b.STDistance(@intersectionPoint) < 1e-8 instead.


This appears to be a rounding error. If I add the following to your code:

SELECT @b.STDistance(@intersectionPoint);

I get ≈ 3 femtometers. Which unless you're measuring something at the atomic scale is probably good enough to be considered as "on the line".

Out of curiosity, what problem are you actually trying to solve?