query tool is inaccurate

[tutey@…]

Please see teh attached screendump. Find the label 1205, in the center.

Now, if I query the vector displayed, at this zoom level, pointing exactly with the very sharp end of the mouse pointer between numbers 2 and 0, it queries all the 3 adjacent polygons, while it should query only the tall and narrow one, which I'm aiming at.

This is only an example. This happens very often. The query tool has much to big tolerance to use it conveniently.

Maciek

[g_j_m]

The radius that the selection tool searches in can be changed in the "Settings:Options:Selection & Measuring" dialog box. I suggest that you reduce the value there. If that helps, please close this ticket.

[tutey@…]

Thanks. I've set it to '1' and still the same problem.

Maciek

[wonder]

I think we should change the setting to be more user-friendly: let users set the selection radius in pixels in map canvas rather than some magic values. (IMHO this applies also to snapping tolerance in project options)

[gsherman]

The changes suggested by wonder are an enhancement to the current functionality. I've moved this ticket to "must-fix" for 0.9.

[tutey@…]

I don't understand why fixing this bug is postponed to 0.9. I'm taking liberty to assign it back to 0.8. If it is fixed or not is a matter of developers, and please don't take it as an insist. But it is unfair to pretend this is an enhacement request, as Gary wrote it.

Rationale:

This issue is critical. I can't imagine a GIS viewer that cannot query the features I point at, but two or more surrounding ones instead.

Postpone it again if you wish, but I'm sure it will be not fair. I'm not sure why it was skipped that easily - maybe there is something unclear in the way I described the problem, thus the missunderstanding. So let me put the issue under your consideration again.

Best, Maciek

[g_j_m]

We're keen to get version 0.8 out, and this lack of precision when querying is not a critical problem. The solution is to have the search radius in units of pixels rather than some other units, which in our view is an enhancement to current functionality.

One still gets the desired geometry in the identify results dialog box - it's just that there are some extra ones there too, hence we didn't consider it as critical.

If you zoom in on your examples, does identify work as expected?

[tutey@…]

The solution is to have the search radius in units of pixels rather than some other units, which in our view is an enhancement to current functionality.

That's a developers point of view. The user does not know or care about the internals. If it is a flaw in desing, which results in a problem, it is a bug for him. And I he is "right".

If you zoom in on your examples, does identify work as expected?

Well yes. But I have to zoom a lot, too much for a normal use. Too much to call it a workaround.

Consider this also from "publicity" point of view - the basic GIS tool - identify - doesn't work as it should. Considering this, what will a user think of QGIS? "If such an elementary tool fails, how would those more sophisticated tools perform; I'd better go get ArcView".

Thanks for revisiting this. Please don't take it as messing with you or other ard working QGIS folks. I really only want to make a constructive criticism on this issue. This is really not trivial and hampers QGIS usability too much to be neglected.

Maciek

[g_j_m]

This problem should be resolved in svn r6160. There was one bug (changes in the identify radius were not being used by the identify code, so always remained at 5). The units for the identify radius have been changed to be a percentage of the map width.

Changing the identify search radius to something less than the default 0.5% (same as the previous 5 values) will now narrow down the search radius. The minimum value is now 0.01%, i.e., a 10,000th of the map width.

[(none)]

Milestone Version 0.8 deleted