id summary reporter owner description type status priority milestone component version resolution keywords cc 14934 Interface improvement for `destination` tags and all other semicolon-separated list values Penegal team "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." enhancement new normal Core list tag semicolon GUI combobox