ST_ClosestPointOfApproach: Non-linear measures in second geometry

[strk]

I found a failing case which is taking time to debug:

select ST_closestpointofapproach(
'LINESTRING M (12.189 42.2132 1432291464,12.186 42.2168 1432291536)', 
'LINESTRING M (12.1721333333333 42.0917333333333 1432291464,12.172 42.091625 1432291466.25,12.17 42.09 1432291500)');

It returns: ERROR: Non-linear measures in second geometry

Doing it at the liblwgeom level it works fine. Filing as a ticket to continue debugging later.

[strk]

Seems to be a robusness issue, because this fails:

ST_closestpointofapproach('LINESTRING M (0 0 1432291464,0 0 1432291536)', 'LINESTRING M (0 0 1432291464,0 0 1432291466.25,0 0 1432291500)');

While this succeeds:

select ST_closestpointofapproach('LINESTRING M (0 0 91464,0 0 91536)', 'LINESTRING M (0 0 91464,0 0 91466.25,0 0 91500)'); 

In the second case I just subtracted 1432200000 from each M value

[strk]

Similarly, these inputs fail:

'LINESTRING M (0 0 40000000,0 0 40000003)'::geometry g1, 
'LINESTRING M (0 0 40000000,0 0 40000001,0 0 40000002)'::geometry g2

While these work:

'LINESTRING M (0 0 10000000,0 0 10000003)'::geometry g1, 
'LINESTRING M (0 0 10000000,0 0 10000001,0 0 10000002)'::geometry g2

[strk]

It may have to do with the cached GBOX rounding 40000002 to 40000004 or something like that: select 40000002::float4::float8; — 40000000

[strk]

Yeah, as the "valid range" seems to include ..04, the ..03 measure from geometry1 is "assumed" to be valid for geometry2, but it isn't. The fix is to NOT RELY on the cached bbox but to always compute it from scratch instead.

[strk]

Fixed with r13569