You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current logic determining the related parent has some drawbacks:
The normal workflow to select a vertex in iD is to select the way first and the vertex afterwards. This is not required in case of a connecting vertex, but this workflow might still be used. In this case the selected way should be used as the related member, and not more or less ramdomly just one of the connected ways.
In case of selecting a connecting vertex directly, iD should not just guess. Instead it should not assign any related parent way.
The current logic fails in case a vertex is included in the way two or more times, when counting the start/end vertex of a cyclic way a a single one. ID allows to draw such ways, therefore, they do exist in the database.
The first and last vertex of a way are well defined, when the way is selected itself, therefore, these shortcuts should be made available in this case. This simplyfies the required workflow. For even more user convienience, nextVertex and previeousVertex can be made the same as firstVertex and lastVertex respectively.
These changes are already made in my pull request #3631 because I had to rework the code anyway in order to provide an interface for #3603 .
The text was updated successfully, but these errors were encountered:
Closing here.. After editing with it this way for a few months, I'm pretty happy with the current behavior of just picking a related parent when there are multiple options. Switching the related parent with \ key is pretty easy to do.
@bhousel
The current behavior is not perfect, but it might be sufficient for your usecases.
The main reason to improve is to allow reusing the related parent and/or navigation logic for other software features like #3604, #3635, and #2206. You wrote in #3926 that you like my suggestion in #2206, which would be just an application of #3635 and the improved related parent logic of this virtex navigation improvement.
The current logic determining the related parent has some drawbacks:
These changes are already made in my pull request #3631 because I had to rework the code anyway in order to provide an interface for #3603 .
The text was updated successfully, but these errors were encountered: