Helper features for direction value (orthogonal direction, toward nearest point at line, etc.)

[PeterBrodersen]

Description

tl;dr: Entering directions numerically as degrees leads to guesses, trial-and-error. Many directions could be derived by existing features or by use of aerial imagery and simply pointing in the correction direction.

More detailed:
As directions are usually parallel or orthogonal with existing features it would be helpful to use derived values from these features as options.

At the moment it is hard to figure out whether a chosen direction matches existing features' directions (e.g. sides of a building where the direction is not specified as a tag, but could be derived from the two points for that line segment). Currently the direction feature simply accepts numerical input as well as increment/decrement in 5 degree steps. It is not easy to know the correct direction in advance.

A workaround is to move the new feature next to the existing feature and changing the direction manually and simply eyeballing whether the the circle sector ⌔ lines up nicely. But this is cumbersome and usually requires trial-and-error when entering a specific direction.

This might break the simplicity principle of iD. However these are mainly suggestions for ease of use and no more complicated in the user interface than adding a new context menu feature. iD can already derive that information for existing features and we should make use of that.

Using existing non-connected lines

Several features usually face specific other features, e.g. benches that often face a path, road or pond, or face directly away from the side of a building.

Some features usually run in parallel with specific other features, such as a traffic sign mapped as a separate node.

Placements directly on walls and other ways

A plaque or other feature hanging on a wall would usually face in an orthogonal direction. Based on the type of feature the default suggestion could be in the direction e.g. facing away or into/inside a building wall/way.

This would simply be a suggestion of (calculated way direction ± 90 degrees). For a corner it might be the average of the two directions (again, facing inward or outward based on the circumstances).

Implementation

Following the simplicity principle of iD this should not be more advanced than e.g. moving a node.

My suggestion is to add a "Set direction" option when right clicking a node.

• The direction should be facing the user's pointer (making it easy to set a correct direction based on aerial imagery as opposed to guesstimate degrees).
• If the pointer hovers over a point the direction should face the point.
• If the pointer hovers over a line the direction should face the nearest point on that line segment.

As some directions should be orthogonal and other should be parallel by their nature this could also be taken into consideration. Otherwise changes in 90 (or 45) degrees steps should be easily possible as opposed to clicking the increment/decrement 18 times to rotate by 90 degrees.

There is already the possibility of flipping the direction (hotkey: v) for a feature. Actually selecting and setting the direction should be just as easy.

Screenshots

Example of a bench where the direction could have the possibility of having its direction set facing the nearest position on a selected way (even if that position on the line does not exist as its own point)

[1ec5]

This would be a huge time-saver for me as I map stuff like traffic signs and historic markers.

I suspect that anything involving a new gesture-based mode would be tricky to design and implement. Maybe as a half-measure, we can address the need by having the direction field’s increment and decrement buttons “snap” to nearby ways’ tangents as well as the 5-degree increments? The choice of nearby ways to consider could differ based on the current preset. It would require more clicking than what you’re proposing, but the direction cone in the canvas will update interactively to show the user how close they are to the desired angle.

[danieldegroot2]

Partial duplicate of #5530. Merged points there.