Bug report #17024
Identify Tool gives false hits for layers with spatial index (MS SQL)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: |  Nathan Woodrow | ||
| Category: | Data Provider/MSSQL | ||
| Affected QGIS version: | 2.18.11 | Regression?: | Yes |
| Operating System: | Win7 32 bit | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 24923 |
Description
Since updating to osgeo 2.18.11 the Identify tool has been randomly selecting objects well outside the 2mm search radius.
I deleted the .qgis folder from my user profile and also deleted the QGIS registry key, but that didn't solve the problem. Nor did creating a new project from scratch.
More testing has shown the behavior only occurs with layers where the "Create spatial index" button has been clicked. Dropping the index restores normal behaviour for the layer. Re-Adding the index causes the erratic behavior to reappear.
I have selected "Map Tools" as the category for this bug report. It may be specific to the MSSQL provider. I only have MS SQL layers to test against.
History
#1
Updated by Martin Bain over 7 years ago
Forgot to say I was using 2.18.9 before updating.
#2
Updated by Giovanni Manghi over 7 years ago
- Priority changed from Normal to High
- Regression? changed from No to Yes
#3
Updated by Damien Smith about 7 years ago
Can confirm this. Even with search radius set to 0, all objects within 20-30 map units are identified. Only appears to affect MSSQL layers with spatial index as stated. No other formats are affected.
#4
Updated by Nathan Woodrow almost 7 years ago
- Assignee set to Nathan Woodrow
#5
Updated by Nyall Dawson about 6 years ago
- Category changed from Map Tools to Data Provider/MSSQL
#6
Updated by Nyall Dawson about 6 years ago
- Status changed from Open to Feedback
Please test with 3.2 and report if the issue still exists
#7
Updated by Damien Smith about 6 years ago
Issue no longer exists in QGIS 3.
#8
Updated by Nyall Dawson about 6 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed/implemented
Thanks for the confirmation!
#9
Updated by Lukasz Sychowicz almost 6 years ago
Nyall Dawson wrote:
Please test with 3.2 and report if the issue still exists
that's right, in version 3.x there is no this bug, but not everyone uses version 3.x. Is it really impossible to fix this for version 2.18 LTR?
Why it is marked as fixed despite it is not?