PostGIS: use ST_Intersects instead of && for bounding box (fixes #6181, fixes #6230) #6347
The backport to
To backport manually, run these commands in your terminal:
# Fetch latest updates from GitHub
# Create a new working tree
git worktree add .worktrees/backport-branch-7-6 branch-7-6
# Navigate to the new working tree
# Create a new branch
git switch --create backport-6347-to-branch-7-6
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick 40f310f5d6591e06c3997ace8648c0a8a1f74229,bd6b73a71567c1272d5e758265e1e921f5d7dce6
# Push it to GitHub
git push --set-upstream origin backport-6347-to-branch-7-6
# Go back to the original working tree
# Delete the working tree
git worktree remove .worktrees/backport-branch-7-6
Then, create a pull request where the
I'm not positive on this but I was trying branch-7-6 in production and ran into some weirdness with mode=nquery and PostGIS layers. I was doing point queries on polygon layers and experiencing inconsistent results across multiple layers - some features would return as a result and some wouldn't. Reverting to the 7.6.3 release fixed things. This looks to be the only addition that could affect those operations but it's not obvious to me why. I'll have to try and narrow it down. Is there anything that might be specific to PostGIS version with this change?
I'm not aware of PostGIS version making a difference for ST_Intersection(), but one thing I noticed is that ST_Intersection() was more picky about SRID than &&. I had to do https://github.com/MapServer/MapServer/blob/main/mappostgis.cpp#L1824 because of that
Hi Even: Back at this and with debugging on with point queries the SQL that gets generated looks something like:
The bounding box is actually just a point in these cases (xmin=xmax, ymin=ymax) which never caused problems. In this case the resulting POLYGON has the same issue where all points in the geometry are the same. The ST_Intersects() function seems to be indeterminate in this case - sometimes it works, sometimes it doesn't.
If I edit the SQL and turn the POLYGON into a POINT, so:
then the correct feature is found.
BTW the MapServer call looks like: