Changes to Selection Resolver behavior

[JimN-LostArt]

This is my rational for changing when the Resolver is activated. My
proposal is to limit it to only when regions are involved. There are
other possibilities, including activate for any overlapping lines, a
global switch, shift-click or ctrl-click to suppress, to name a few.
The issue (#1616) in the bugs db is at:

http://bugs.grouplens.org/show_bug.cgi?id=1616

Selection Resolver is always activated when clicking near an
intersection, but
is rarely useful:

-If user is moving the intersection, it doesn't matter, but the user
still must pick.
-Often, the choices are several "unnamed" paths or sidewalks, or
street names
repeated twice, making them useless.
-Often the names are not readily visible on the map, or if they are,
the user
must look for the name for his/her desired segment.

In addition to intersections, the resolver is also not that useful for
objects close together, like crossed lines. Without the resolver there
is quick visual feedback if the wrong object is selected, the user can
click on the correct object faster than selecting the object from a
menu.

The cases there the resolver is useful is when line objects are
parallel; one
nearly on top of the other:

-Points are usually off from byways, but in cases where they are
together, the
point should always be selected, as byways can usually be selected
from
elsewhere. (I haven't checked if this is the actual behavior).

-Byways on top of one another is a map error, and can be corrected
once, and
never be an issue again, although paths along roads may still be a
problem at low (vector) zooms.

-Regions often run parallel to other regions and to byways, so the
resolver is
useful when selecting regions.

So I propose to limit the resolver to cases where there is at least
one region in the choice. Other ideas?

Thanks,
Jim

[JimN-LostArt]

Same but with formatting fixed:

[Reid Priedhorsky]

Since it seems like the greatest annoyance is when only byways are
involved, what do you think about disabling it only when all involved
features are byways?

Does the point-priority behavior happen already when the resolver is
turned off, or does that require additional work (without the resolved,
whatever is on top wins, right?)?

If we do pick your behavior, we'd need to have routes be a trigger for
the resolver, too, though I believe they have some special-case
selection behavior already. They fit your criteria for parallel features.

Reid

[James Nordgaard]

On Fri, Mar 12, 2010 at 10:57 PM, Reid Priedhorsky <re...@umn.edu> wrote:

Since it seems like the greatest annoyance is when only byways are involved, what do you think about disabling it only when all involved features are byways?

That would be just about as good. Personally, I have points and regions turned off most of the time, so I can't speak for any difficulties with them.
 

Does the point-priority behavior happen already when the resolver is turned off, or does that require additional work (without the resolved, whatever is on top wins, right?

I checked. Points are always selected over byways, even if the byway is already selected.
 

)?

If we do pick your behavior, we'd need to have routes be a trigger for the resolver, too, though I believe they have some special-case selection behavior already. They fit your criteria for parallel features.

Same as above. route selection currently has to be turned on, so they it's not an issue. I don't see a problem with using SR only when anything but byways are close by. People who edit with points and regions on may have a different opinion.
 

Reid

 

[Reid Priedhorsky]

On 03/14/10 14:23, James Nordgaard wrote:
> On Fri, Mar 12, 2010 at 10:57 PM, Reid Priedhorsky <re...@umn.edu> wrote:
>
>> Since it seems like the greatest annoyance is when only byways are
>> involved, what do you think about disabling it only when all involved
>> features are byways?
>>
>>
> That would be just about as good. Personally, I have points and regions
> turned off most of the time, so I can't speak for any difficulties with
> them.

> I don't see a problem with using SR only when anything but

> byways are close by. People who edit with points and regions on may have a
> different opinion.

It seems like we're in agreement, then. Can you resubmit your patch such
that the the selection resolver is disabled if only byways would be in
the list?

Thanks,

Reid

[Reid Priedhorsky]

Thinking more about parallel blocks: what about roadside paths in zoomed
out levels? I wonder if the heuristic should be: disable the selection
resolver if all objects in question are byways *and* they all share a
node (intersect).

Reid

[James Nordgaard]

Yeah. Actually, I took another look at the Selection Resolver. It has a neat feature that I wasn't aware of: When you scan down the list, the actual blocks get highlighted. This effectively weakens my arguments against it for intersections; for all but moving the intersection. The upshot is that I decided to rethink my proposal for scaling back the tool, and for now do nothing.

Perhaps all it needs, eventually, is to allow intersection moving without having to select from the list, and maybe a switch to turn it off. For now, you can bump the priority down and move it back to unassigned (or I can). I'm focused on other things right now.

Jim