Interface improvement for `destination` tags and all other semicolon-separated list values

[Penegal]

Hello, there.

I started to see to destination* tags (destination, destination:forward and destination:backward, but that ehancement could be useful for any semicolon-separated values), and noticed that some improvement could be done for this. First, I will explain my reasoning, to see if someone sees an error in it: destination* tags are used to put in OSM destinations as displayed on road signs; such destinations vary widely along a road, because farthest destinations are displayed for tens, or even thousands, of kilometers, whereas closest can be only displayed for a couple of kilometers. For instance, along a oneway road, the destination values could be these:

             Alpha                          Bravo                                   Charlie                         Delta
--->------->---○---->---------->--------->----○------->----------->---------->-------->○----------->------------>------○
 Alpha;Charlie          Bravo;Charlie             Charlie             Delta;Charlie                 Delta

I'm pretty sure I'm not the only one to see the problem here: putting the destinations in the destination tag here, in its current interface, is not very practical; the better way I can think about here is:

1. cut the highway line at Charlie, and put destination=Charlie on its left part;
2. cut the line at Alpha, and add Alpha; in destination on the left part;
3. cut the line at Bravo, and add Bravo; in destination on the left part;
4. cut the line between Bravo and Charlie, at the point Delta starts being put on the signs, and add Delta; on the right part;
5. cut the line at Charlie, and remove Delta; in destination on the right part.

The cuts in the highway line are inherent to the OSM modelling, and could be made all at once, by selecting the nodes on which the cutting should be made, and then using P to cut, but, then, all segments of the highway should be tagged separately, and without much assistance from autocompletion because it is semicolon-blind, seeing the value as a whole, not as a list of values. That could quickly lead to "Ow, my head…" moments on long roads, because you would have to choose between

1. tagging the segments one after another, but then you will have to constantly keep in mind where each name started and stopped appearing, or
2. trying to gather the modifications as I did earlier, but that is no longer practical when several destinations keep appearing and disappearing at random points along the road.

Besides, in this workflow, the user will have to constantly and mentally extract the items of the semicolon-separated destination* lists for keeping them up-to-date along the highway, whereas jOSM could easily do that for him.

Recording all the destinations when driving along the road already necessitates a bit of structure, so modelling should not bring it up again; still, this data can be very important, for instance for car GPSes, which use destination* tags to help the driver finding its way, as road signs can be far more practical than a crossing schema.

I thought about a way to improve this; please note that this could be use for each tag whose value is a list of semicolon-separated values. The popup for values of destination* tags could be like this one:

+----------------------------------+
|                                  |
|   +------------+                 |
|   | Alpha      |                 |
|   | Bravo      |                 |
|   | …          |                 |
|   |            |                 |
|   |            |                 |
|   |            |                 |
|   |            |                 |
|   |            |                 |
|   |Another     |                 |
|   +------------+                 |
|                                  |
|                                  |
|   +----+  +---------+            |
|   | OK |  | Cancel  |            |
|   +----+  +---------+            |
|                                  |
+----------------------------------+

This list would be a combo box; I put the input area atop it, but it could be above it. This list would contain last used values, values existing on nearby highway, or a combination of both, and the use would only have to Ctrl-select the values to be applied to the selection, without having to bother about mentally eliminating the semicolons when reading the screen. When several highway are selected, the items common to all of them would be rendered in the list as selected , and the items present in only some of them would be rendered with a somewhat shaded background, to highlight the fact that they are not used elsewhere.

This way, when a destination appears on the signs, I would only have to:

1. select the highway on which this destination is displayed;
2. edit their destination and add the value to all of them.

That would have one clear drawback, though: the order of the elements would be lost, unless there is a way to order them in the combo box, but, IMHO, the items order is less important than them being in the list; besides, regarding the case of road signs, it only needs a fraction of seconds to find an item on the signs, even if it is in a random place in the displayed list.

I know neither how this could be integrated with the existing GUI, nor the amount of development that would need, but I must insist that this could be used for any semicolon-separated list values, especially those with some values to be propagated to neighbor elements and not other values, as with highways. Maybe this interface should be automatically used when the edited tag is in an internal list of well-known semicolon-separated list tags, to also improve their management.

Hoping this will help,

Regards.

[bastiK]

Hi, thanks for your ideas! Regarding the first part, this is not the right place to make such a suggestion. As JOSM developers, we try not to invent and establish new tagging practices, but implement proposals, that appear to have already wide approval in the community. Please refer to the OSM forum, wiki, mailing lists, etc!

With respect to the new input for semicolon-separated lists: We have something similar already in the presets, e.g. Restaurant/Cuisine. One distinct disadvantage of this GUI is, that you cannot enter custom values. Suggestions are welcome, how to improve that. Your input add tag and edit tag dialog has a similar problem: How to add multiple new values?

Please note, that there are multiple wide spread tagging schemes, where the order of elements in the semicolon-separated list does matter, for example ​Lanes and, in fact, ​Destination.

[Penegal]

Replying to bastiK:

Hi, thanks for your ideas! Regarding the first part, this is not the right place to make such a suggestion. As JOSM developers, we try not to invent and establish new tagging practices, but implement proposals, that appear to have already wide approval in the community. Please refer to the OSM forum, wiki, mailing lists, etc!

Hello.

I don't understand: I wasn't suggesting new practices, merely stating what I knew, or what I thought to be; was I wrong on something?

With respect to the new input for semicolon-separated lists: We have something similar already in the presets, e.g. Restaurant/Cuisine. One distinct disadvantage of this GUI is, that you cannot enter custom values. Suggestions are welcome, how to improve that. Your input add tag and edit tag dialog has a similar problem: How to add multiple new values?

The new values could be added to the combo box one by one with its input field. Currently, new entries have to be separated by a semicolon; in my proposal, this key (as in keyboard) would only have to be replaced by an ↲ key. This is different, IMHO, with the cuisine tag, which has a more or less finite list of items, whereas possible destination values are far more important, virtually unlimited.

Please note, that there are multiple wide spread tagging schemes, where the order of elements in the semicolon-separated list does matter, for example ​Lanes and, in fact, ​Destination.

The list could be ordered by the user: at least here in France, and it seems logical to be the case elsewhere, the destinations are put on the signs in order of importance, the more important destination being at the top. There could be, in the window, a tab to order the current selection. As the order by importance is the same on every point of the road, items which are only used on some selected highway segments could also be in the to-be-sorted list.

I must amend my example because it doesn't reflect an IRL set, with destination items displayed on signs ordered by importance:

             Alpha                          Bravo                                   Charlie                         Delta
--->------->---○---->---------->--------->----○------->----------->---------->-------->○----------->------------>------○
 Charlie;Alpha          Charlie;Bravo             Charlie             Delta;Charlie                 Delta

There, the order could be

1. Delta
2. Charlie
3. Alpha
4. Bravo

On exiting the popup by clicking OK, the order would be applied on each highway segment, but only for the items the highway have in its destination tag.

[bastiK]

Replying to Penegal:

Replying to bastiK:

Hi, thanks for your ideas! Regarding the first part, this is not the right place to make such a suggestion. As JOSM developers, we try not to invent and establish new tagging practices, but implement proposals, that appear to have already wide approval in the community. Please refer to the OSM forum, wiki, mailing lists, etc!

Hello.

I don't understand: I wasn't suggesting new practices, merely stating what I knew, or what I thought to be; was I wrong on something?

I was just a bit confused: Where I map, it is not possible to load an area that contains several major destinations, it would simply too much data. On top of that, the highway is usually mapped already and highly segmented (maxspeed etc.). The destination tag should go on the segment right after the traffic sign and not along the entire length of the road.

Please note, that there are multiple wide spread tagging schemes, where the order of elements in the semicolon-separated list does matter, for example ​Lanes and, in fact, ​Destination.

The list could be ordered by the user: at least here in France, and it seems logical to be the case elsewhere, the destinations are put on the signs in order of importance, the more important destination being at the top. There could be, in the window, a tab to order the current selection. As the order by importance is the same on every point of the road, items which are only used on some selected highway segments could also be in the to-be-sorted list.

I must amend my example because it doesn't reflect an IRL set, with destination items displayed on signs ordered by importance:

             Alpha                          Bravo                                   Charlie                         Delta
--->------->---○---->---------->--------->----○------->----------->---------->-------->○----------->------------>------○
 Charlie;Alpha          Charlie;Bravo             Charlie             Delta;Charlie                 Delta

There, the order could be

1. Delta
2. Charlie
3. Alpha
4. Bravo

On exiting the popup by clicking OK, the order would be applied on each highway segment, but only for the items the highway have in its destination tag.

In my experience it is a mix of importance/size and proximity to the target. Sounds a bit experimental and like a feature that should be tested in a plugin first.

Overall, I think it is a good idea that semicolon-separated tag-values are presented as a list of entries in the GUI. But at least to me, it is not clear in detail, how this can be realized.

[Penegal]

Feel free to ask me if there are some thing I could explain; I don't know yet if my idea is useful, but am willing to help you evaluate that.

[Don-vip]

Replying to bastiK:

Overall, I think it is a good idea that semicolon-separated tag-values are presented as a list of entries in the GUI. But at least to me, it is not clear in detail, how this can be realized.

+1. We could reuse (and improve) the "Change list setting" dialog from Advanced Preferences. A toolbar should be added to allow to move values up/down.