range of directions on viewpoints

[eehpcm]

I recently mapped a tourism=viewpoint and tried to specify a range on the direction. When I deselected the object iD's internal validation silently removed the range and left only the first angle. So direction=90-270 became, without my knowing, direction=90. Only when I selected the object again did this behind-the-scenes modification become apparent.

It is debatable if this is correct behaviour or not. Allowing direction to specify a range seems to have first appeared in the wiki page for tourism=viewpoint, but I can't find a proposal for tourism=viewpoint. The range idea then appears to have been imported into the wiki page for the direction tag itself, again without a proposal or much discussion. So it could be argued that direction ranges should not be permitted or it could be argued that OSM tags are anarchic so if somebody wants to do that then they can.

So, should iD be restricting the range? And if so, should it do so silently or should it either refuse to let the user enter a range (refuse to accept the - sign and characters that follow it) or pop up a warning dialogue?

[bhousel]

related #4755

We can't support the ranged values currently, but we could add support for rendering them by changing 1. the code to parse the values and 2. the code to render the viewfields.

The range idea then appears to have been imported into the wiki page for the direction tag itself, again without a proposal or much discussion. So it could be argued that direction ranges should not be permitted or it could be argued that OSM tags are anarchic so if somebody wants to do that then they can.

Yes, it's really best to think of the OSM tagging as anarchic. People can propose stuff and write stuff on the wiki, but that doesn't mean anybody will support it.

[eehpcm]

@bhousel

We can't support the ranged values currently, but we could add support for rendering them by changing 1. the code to parse the values and 2. the code to render the viewfields.

Sounds like a lot of work. Especially as it (currently) isn't rendered any differently on OSM carto if direction is specified as a single value, or as a range, or is not given at all. In fact, I'm so old that I remember when iD didn't show the direction in the overlay. So I'm not too worried if the overlay doesn't support it, but it's counterintuitive when iD changes things behind my back. For example, if iD made it more obvious that it disallowed a range 0-180 then people might instead choose direction=90 instead of what iD silently gives them - direction=0.

[bhousel]

So I'm not too worried if the overlay doesn't support it, but it's counterintuitive when iD changes things behind my back. For example, if iD made it more obvious that it disallowed a range 0-180 then people might instead choose direction=90 instead of what iD silently gives them - direction=0.

iD is not changing anything behind your back. If you type an unsupported value in a numeric field, iD will change it. You can see this pretty clearly.

You can also use the raw tag editor to type whatever values you want.

[eehpcm]

@bhousel

iD is not changing anything behind your back. If you type an unsupported value in a numeric field, iD will change it. You can see this pretty clearly.

Erm, nope. I type in 90-270. It's clearly there. I click on the tick (check mark) to say I'm done. No complaint. I select the object again, direction=90. It changed it behind my back.

Oh, I see why you think the change visible. If I add/change something else after entering a range for the direction, iD does visibly change it. But unless I'm looking at the direction I just entered instead of what I'm about to enter next, I don't see the change happen and don't notice it.

You can also use the raw tag editor to type whatever values you want.

Ah, that works. And it's even reflected in the direction box. But it's a bit fragile. It goes away if I try to do anything in the direction box. Not very intuitive to anyone who hasn't been following this issue.