Follow operation should prefer the focused way

[1ec5]

The “follow” operation added in #8671 stops when encountering a node that’s shared among multiple features. iD already keeps track of the “focused” way for the purpose of reliably navigating back and forth among its vertices using the keyboard. It would be natural to extend this capability to the follow operation, so that the user doesn’t have to think as much about other connecting ways after choosing a way to follow. Invoking the follow operation would focus the way, and subsequent follow operations would choose that way from among the candidate ways.

https://github.com/openstreetmap/iD/blob/76990349bd2442a80b4c9bfb2440ea5c7a00a2d1/modules/modes/select.js#L150 https://github.com/openstreetmap/iD/blob/76990349bd2442a80b4c9bfb2440ea5c7a00a2d1/modules/modes/select.js#L48-L50

[Pho3b]

Hi and nice to meet you @mbrzakovic @1ec5 , i would like to try and work on this issue if possible.

[thyrhone]

is it still possible to work on this?

[1ec5]

Thanks for your interest! There’s a fix available in #8978; perhaps you could help review it?

[sherryboxall]

Hello @mbrzakovic @1ec5 ,

I would like to help work on this issue if possible. Thank you!

[Dustpie]

Can I still help on this issue if possible? Thank you!

[Gua00va]

Hey!! I want to work on this issue. I'm new here so I'm really excited to start contributing. Please assign it to me.

[k-yle]

This issue has already been fixed in two conflicting PRs: #8978 and #9340

I'm guessing the suprising interest in this issue is because it has a "good first issue" label. @tyrasd it might be good to add this label to some other issues like #9452, #9217, #9448, #9441, #9440, #9312, #9402, #9400, ...

[1ec5]

Right, GitHub has a feature that suggests issues labeled as https://github.com/openstreetmap/iD/labels/good%20first%20issue to users, but it doesn’t consider whether there are outstanding PRs already linked to them.

[DujaOSM]

Objection, your honor! Implementing this will break workflow in a very common use case where we fill up the space with landuse polygons. Let me illustrate: I'm drawing a farmland here, following the existing forest boundary. When I encounter a tripoint with a meadow, as in the screenshot, I want to continue following the meadow. Therefore, I want iD to stop there and prompt me where to continue. Implementing this change would mean that it would just continue following the forest (something I rarely if ever do), so it will make my workflow very error-prone.

[1ec5]

The current behavior makes the follow operation useless in some common situations. For example, I happen to know that there’s a fence surrounding this quarry, which is thoroughly connected to surrounding landuse areas. I can’t use the follow operation at all, because every single node is connected to more than one area. Yet it doesn’t even matter which area it follows:

I take it you’re jamming the F key until it pauses on something. I do that a lot when editing OpenHistoricalMap, in order to duplicate a way and ensure that it’s connected to the original way. It’s a critical workflow for that project, but it’s also hampered by this issue. What if we initially pause but continue along the focused way after the second keystroke? Or what if we detect that the F key is on repeat and pause for a second or two, giving you a chance to ease up on the F key?

10155 also had a good idea about considering the angle of each candidate way.

[DujaOSM]

But in the fence use case, it's just the software being lame: yeah, the current point connects multiple areas, but they share both the previous and next node, so there's no ambiguity. The algorithm could be amended to work in that case as well, rather than changing the whole workflow.

(And, btw, related #9734 could be tackled along the way, seems simple enough).