Avoid deselecting feature that goes out of view

[1ec5]

iD automatically deselects a feature when it goes out of view. (As far as I can tell, this has always been the case.) iD should avoid deselecting features for this reason, or it should at least be more lenient. For example, it’s currently very difficult to relate a place POI to a boundary relation unless the place is very small in area. (By analogy, I find it annoying to use a text editor that insists on moving the insertion point when I scroll up and down.)

On the other hand, it could look weird if the user had accidentally panned the feature out of view. The tag editor would be open with no clear target. Perhaps there could be an “off-screen” indicator, sort of like those “distance to” arrows at the edges of paper maps, plus a keyboard shortcut to jump to the selection. Or maybe #3622 could be fixed instead. 😉

/ref #3622 (comment)

[HolgerJeromin]

Same with zooming out

[BjornRasmussen]

I really don't see this as an issue, since the multiselected objects don't get deselected when you move the map, and that is when you would really need this feature.

[1ec5]

The case where I really need this feature is when I’m piecing together a route relation where the nearest existing member is clear across town. (Most recently, this happened as I pieced together a bike route relation from spotty signage.) One of #3622, #3487, or this issue would make my workaround unnecessary:

1. Select a new bus stop, and open the Measurement panel. Jot down the coordinates.
2. In a separate tab, open osm.org’s page for the bus route relation or one of its existing members.
3. Select the existing member by searching for e.g. w123 or n123.
4. With the existing member in view, draw a new line and add it to the relation without giving it any tags.
5. Begin appending to the line.
6. Without ending the line, search for the coordinate you jotted down in the first step.
7. Extend the tagless line to near the new bus stop.
8. Add the bus stop to the route relation.
9. Delete the tagless line.

[quincylvania]

@1ec5 How do you reproduce this? I tried clicking on a feature then panning far away and it stayed selected. Safari and Chrome.

[Nakaner]

I haven't digged through the history in this bug tracker but deseselecting features when going out of view could preserve us from people accidentally deleting or modifying objects.

[jguthrie100]

Might be worth popping up a warning if something out of view will get deleted or edited

[1ec5]

How do you reproduce this? I tried clicking on a feature then panning far away and it stayed selected. Safari and Chrome.

Huh, you’re right, features no longer go away when panning away from them. That certainly makes it easier for me to add place=city POIs as labels of boundary relations as I’ve been doing lately.

deseselecting features when going out of view could preserve us from people accidentally deleting or modifying objects

This is how it used to behave when I originally opened this issue. (I opened the issue as an alternative to #3622 when it seemed like there was opposition to that idea.) No idea when the behavior changed. Now I feel a bit silly for that circuitous workaround!

iD prevents the user from deleting or moving a feature that isn’t fully visible. Only the tag editor remains usable after moving the selected feature completely out of view.

[BjornRasmussen]

I guess that this should be closed now?

[quincylvania]

Huh, you’re right, features no longer go away when panning away from them.

I'm not sure when this was changed either but it appears to be live on osm.org and I haven't heard about any related problems. I hope it's a helpful change!

I do think we should work on #2962 and #5001 to keep the feature selected, visible, and editable when zoomed out as well.