Since the update of the meter distance computation (#10 in util, spatialjoin commit 42c52819b), a within-distance join can silently drop a matching pair of polygons. With spatialjoin at d1170ee (util at 9a8ca0a) the same input produces the correct result, so this is a regression.
For example, with the two input polygons below (an approximated Germany and the London Eye, taken from a QLever unit test) and a distance of 1000 km, no pair is reported at all. The correct result is the pair with meter distance 426521, well within the threshold.
I think the root cause is an integer overflow in distToSegment in geo/Geo.tpp. The projection parameter t is computed in the coordinate type, and for 32-bit web-Mercator coordinates the products overflow. The distance then falls back to the distance to the segment endpoints. This inflates the box-to-box distance, which is computed via the segment distances of the box edges. The probing in withinDist finds the correct distance and a correct euclidean upper bound, but the check dist(boxA, boxB) > euclideanDistUpperBound then wrongly concludes that nothing can be in range.
A possible fix is a promotion to double in the computation of t. The line above it, computing d, already has it.
germany POLYGON((7.20369317867016 53.62121249029073, 9.335040870259194 54.77156944262062, 13.97127141588071 53.7058383745324, 14.77327338230339 51.01654754091759, 11.916828022441791 50.36932046223437, 13.674640551587391 48.68663848319227, 12.773761630400273 47.74969625921073, 7.58917 47.59002, 8.03916 49.01783, 6.50056816701192 49.535220384133375, 6.0391423781112 51.804566644690524, 7.20369317867016 53.62121249029073))
london POLYGON((-0.1198608 51.5027451,-0.1197395 51.5027354,-0.1194922 51.5039381,-0.1196135 51.5039478,-0.1198608 51.5027451))
Since the update of the meter distance computation (#10 in
util, spatialjoin commit 42c52819b), awithin-distancejoin can silently drop a matching pair of polygons. With spatialjoin atd1170ee(util at9a8ca0a) the same input produces the correct result, so this is a regression.For example, with the two input polygons below (an approximated Germany and the London Eye, taken from a QLever unit test) and a distance of 1000 km, no pair is reported at all. The correct result is the pair with meter distance 426521, well within the threshold.
I think the root cause is an integer overflow in
distToSegmentingeo/Geo.tpp. The projection parametertis computed in the coordinate type, and for 32-bit web-Mercator coordinates the products overflow. The distance then falls back to the distance to the segment endpoints. This inflates the box-to-box distance, which is computed via the segment distances of the box edges. The probing inwithinDistfinds the correct distance and a correct euclidean upper bound, but the checkdist(boxA, boxB) > euclideanDistUpperBoundthen wrongly concludes that nothing can be in range.A possible fix is a promotion to
doublein the computation oft. The line above it, computingd, already has it.