Add direction dial for numeric *:direction fields

[tordans]

Closes #5530
Ping #9733, openstreetmap/id-tagging-schema#2081

This PR adds a dial control to the numeric direction fields.
Features:

• Users can drag the dial to change the value in steps of 1 (regardless of the specified increment property
• Users can hold down shift to change values only based on the increment (in the video that is 5)
• Clicking into the dial changes the value to where the user clicked
• The state is synced between map, fields, dial

Site note: The increment features works differently on the dial than on the +/- buttons. The buttons increase in +/- steps so 3 becomes 3+5=7. The dial jumps to either 5 or 10. — I think this inconsistency is OK. We keep the backward compatibility for the buttons and the dial works more natural like this IMO.

Video:

Bildschirmaufnahme.2026-03-25.um.18.32.54.mov

---

This code is created using LLM tools. I reviewed it and iterated on it for a while to get into a shape that I find easy to understand and that has a clean split between the existing features and the new additions.

Regardless, I will keep this as a draft first so we can discuss the UX and possible edge cases that I missed, first. But if anyone want to, the code can be reviewed from my point of view.

[tordans]

Testing: Multiple values ✅

The dial is deactivated in this case. The cursor on hover on the dial is the "cannot do anything" cursor.

---

Test-Link: https://pr-12104--ideditor.netlify.app/#disable_features=boundaries&map=20.01/54.20815/10.42527&background=Bing&locale=en&id=n-1,n-2 => Create a traffic sign for example.

[tordans]

One question that was raised during development was, if we should extend the fields like https://github.com/openstreetmap/id-tagging-schema/blob/main/data/fields/direction.json with minValue, maxValue properties to make sure users only put propper values in. The code guards against wird values, but still we have those properties so any reason not to use them? – I would create a PR in the tagging schema if agreed.

[tordans]

Unsure about the way the code is split out from input.js. A function that returns a function is not ideal from a complexity point of view. But it does help to keep the changes to input.js small. Another option would be to inline this in input.js and look into extracting a bit of helper code out where possible.

[1ec5]

As currently designed, the dial occupies the right end of the field’s header bar, insetting the bar to the left. This is a clever way to maximize the dial’s height while minimizing the overall field’s height. However, I’m concerned that inconsistent placement of the header bar could lead users to misclick. #12005 would add more buttons to the bar, making consistency even more desirable.

Since the dial can apparently track the cursor outside of its bounds, maybe we don’t really need to make the dial that big. But if we do, I think we could get away with just making the field taller. It would give us space for a Reverse Direction button similar to the one in the One Way field. I hit V all the time on directional features. For example, I’ll often map a traffic sign and duplicate it to represent the same sign facing the other side of the road.

[tordans]

However, I’m concerned that inconsistent placement of the header bar could lead users to misclick.
…
Since the dial can apparently track the cursor outside of its bounds, maybe we don’t really need to make the dial that big. But if we do, I think we could get away with just making the field taller.

We can try this, but I do not expect it to look great.

• If the dial is just the height of the input, I expect it to be too small to feel like a nice UI; the shift-case would not look good either.
• Making the field bigger in height did look weird
• My ideal from 12005: I think we need to use a different place for those Buttons anyway (see Show and edit related subtags in the inspector (check_date, note/description, source, conditional, numeric, other) #12005 (comment)) and also the direction field should not have those extra options (its not something that usually has a side, subtags or similar. Maybe source.

It would give us space for a Reverse Direction button similar to the one in the One Way field. I hit V all the time on directional features. For example, I’ll often map a traffic sign and duplicate it to represent the same sign facing the other side of the road.

Like the idea. But we might want to track this separately. One idea I have is to remove the undo button, which AFAIR we only have for this field(?) and use that space for a new button. Or an inline "labe/button" in the field like the "reverse"-text-button for oneway.

[tordans]

Quick notes from a talk with @tyrasd at a meetup:

• Maybe remove undo option which we only (?) have in this field; frees up space
• No new idea on a better position / layout – stick with what we have in the preview now
• Add support for ranges like 120-210; First click set the line (one value), then option+drag to change the cone size; Drag without option moves the values as is with different from-to values
• Leave cone on map as is; will have many edge cases if we try to sync the dial style with the map