Relations are not always easily distinguishable

[NE2]

If you have several relations for different parts of a route, like those on ​http://wiki.openstreetmap.org/wiki/Interstate_Highway_relations (some routes are split by state or direction), there's no way to distinguish them in the relation list on the right if you use the tags such that they apply to the underlying elements (so ref is just 95 or I 95 and name is either blank or a name like "Delaware Turnpike").

This specific case would be solved by including addr:state and direction tags if present, but there are many other possible situations where this could cause a problem. I suggest supporting a new relation_name tag that would give each relation a unique name like "Interstate 95 in Delaware (northbound)".

[stoecker]

Hmm, JOSM bug tracker is not really to right forum to introduce new tags. If the tag is used in database, then JOSM will support it.

[rickmastfan67]

You know, I think the easy way to do what NE2 is asking is to combine parts of the relation to display them on the right hand side of the screen. For instance, if a relation doesn't have a name tag, but does have the "description" tag, display the "description" name instead of the "ref" tag. It could go a long way in what NE2 is suggesting without adding a brand new tag.

Here's an example:
For instance, relation 396362 is for I-95 in Delaware. As of right now, when you load the relation in JOSM, in the relation menu, it just shows it as "95", which is the "ref" tag. If you had other I-95 relations loaded, you would have to check each one to figure out which one you wanted to edit. But, it has a "description" tag with "I 95 (DE)" in it. If you could show the "description" tag on the right in the relations area instead of the "ref" tag (unless a "name" tag is present), this could be solved right away. Plus the "description" tag is an official tag. ;)

[alv]

JOSM seems to display the contents of note=* in the relation list; at the moment 55 900 relations have a note=*, whereas 13 500 carry a description=*. This usage of note=* is a bit different from note=* used on ways and nodes. I'm inclined to believe mappers have used it on relations because it makes editing easier, when description=* would be more in line with the other uses of these tags outside of relations. It would be best if JOSM were to use the description=* before a note=*.

[jttt]

As a workaround, you can use ​http://josm.openstreetmap.de/wiki/NameTemplate to display relations or other primitives in way that suits you.

[alv]

Found out that, locally, to use it one only needs to set the advanced preference relation.nameOrder to the array copied from the source code, with "description" added at the suitable row. Simply adding "description", to gui/DefaultNameFormatter.java line 86 (don't have dev environment set up atm) would do the same for all who haven't yet set a custom relation.nameOrder. But first I might have to initiate a mailing list discussion about note=* and description=* on relations, now that I've pondered the issue for some time.

[lonvia]

I'd like to resurrect this ticket because 9 years later the name tag on route relations has pretty much become "whatever makes me find the relation in JOSM's relation list". I'm exaggerating but it would be really great if we could eliminate JOSM as an excuse for abusing the name tag. ;)

'relation.nameOrder' is a nice start to improve what is displayed in the relation list but it is not powerful enough. We need tag combinations. Just look at what the wiki expects to put into the name tag for PTv2 relations (​https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus).

I've looked into the 'name_template' attribute for the presets and they are perfect for the purpose. The tiny problem here is that the name templates can only be defined together with a preset entry. So I can't write a custom preset that just sets name templates for the routes and otherwise uses the default route preset templates.

I see two possibilities here: a) Make name templates independent from present items and allow people to define custom template lists similar to the preset lists, b) Start using name templates in the default presets of JSOM and just get better naming for all.

What do you think? Is one of those doable? Or is there another way to influence the relation list output I'm not aware of?

[stoecker]

Start using name templates in the default presets of JSOM and just get better naming for all.

Sure, why not. Propose a patch for better name display.

[matthijs]

I have also ran into this issue, in particular for (hiking) routes. I've previously proposed a patch (on github, forgot to create a ticket here) that solves two issues for routes: Include the type of route (e.g. "hiking route" instead of just "route") in the name, and support "from" and "to" tags for the name (as an alternative for name/ref/note/...). The patch is here: ​https://github.com/JOSM/josm/pull/75

I came across this ticket when I wanted to create a ticket for this issue, which pointed me at the name templates feature that I was previously unaware of. I've played with this for a bit today, and I think it would be beneficial to implement this with name templates instead of adding hardcoded special cases in the code. This makes it more scalable and flexible to define custom names for specific presets and/or custom filters. As an added bonus, users could in theory also override these names (but this does not currently work, see below).

Replying to lonvia:

I see two possibilities here: a) Make name templates independent from present items and allow people to define custom template lists similar to the preset lists

I believe this is already possible. When looking for a name template, the code (TaggingPresetNameTemplateList.findPresetTemplate()) considers all presets with a name template, and uses the first one that matches the current object. Even more, IIUC, if the preset defines a name_preset_filter, only that filter is checked to see if the name_template should be used. Furthermore, you can define a preset without any input fields (or even keys), and then it is hidden in the UI.

For example, I added this preset:

        <!-- This preset exists only to assign a name to routes -->
        <item name="Route Name" type="relation"
                name_template="?{'{route} '|''}{type} ?{'{special:localName}' | '{ref}' | '{from}-{to}' | 'from {from}' | 'to {to}' | '{note}' | '{special:id}'}"
                name_template_filter="(type=route | type=superroute)"
        />

This changes the naming for route and superroute relations. Because this determines (almost) the *entire* displayed string, it must also display the relation and route type. Also, this template essentially duplicates the (for route relations) relevant part of DefaultNameFormatter.DEFAULT_NAMING_TAGS_FOR_RELATIONS, with its priority of which tags should be preferred, but I do not think this is a bad thing (Even more, maybe some or even most of the hardcoded naming stuff in DefaultNameFormatter could be replaced with name templates?).

The names generated by the (above) template are slightly different from what DefaultNameFormatter generates though:

• The format is slightly different, e.g. "route name_of_route (123 members) instead of route ("name_of_route", 123 members)` (this omits the route type to just illustrate the formatting difference).
• The various parts of the relation are not localized (e.g. the word route is translated by DefaultNameFormatter.getRelationTypeName, but can (AFAICS) not be translated by the template. I am not sure how problematic this is. I guess it could be solved by expanding the template syntx, but I'm a bit afraid this will lead to more complex syntax and hard to read templates as well.
• This does not respect the osm-primitives.localize-name primitive for named relations (the {special:localName} just always uses the local name, while DefaultNameFormatter.getNameTagValue() (via formatLocalName()) checks the preference first). I guess this could be easily solve by using something like {special:maybeLocalName} or something like that.

Replying to lonvia:

b) Start using name templates in the default presets of JSOM and just get better naming for all.

I would also like to see this - even if users can define their own naming patterns, improved defaults are always better.

However, there does seem to be quite a bit of infrastructure around DefaultNameFormatter currently, like (as already suggested above) translations and some preferences, but also name formatter hooks (for plugins?). None of these can trivially be supported by the name templates, so this would either mean losing these features, or having them for some names but not others, which might not be ideal.

I've also noticed that the template parser is currently a bit limited. In particular, I could not use ? as part of the output (that would be tokenized as the start of a ?{ ... } construct, even when it occurs inside a quoted string inside the template). Similarly, I think that nesting ?{ ... } is not currently supported (but I'm not sure I thoroughly tried this).

There is also one caveat wrt user preset overrides currently - It seems that the *first* matching preset with a name pattern is used, and the internal presets are by default the first preset file to load (there is also no GUI way to re-order, though I believe removing the internal presets and re-adding it after custom presets would work). This means that if we ship name templates in the default presets, it because a bit more tricky for users to use their own instead. Maybe this can be solved by documentation, and/or adding a order GUI, or prepending custom preset files instead of appending (with documentation for existing users, also I'm not sure if preset order is relevant for other parts of the code). Simplying reversing the list of presets for determining the name template might be an even easier solution, though that potentially changes behavior for users that have configured their own presets with name templates (but I guess it wouldn't be too hard for them to adapt their presets, if they even exist).

[matthijs]

I've also noticed that the template parser is currently a bit limited. In particular, I could not use ? as part of the output (that would be tokenized as the start of a ?{ ... } construct, even when it occurs inside a quoted string inside the template).

Oh, seems this is not true - a ? can be escaped with \ (according to docs at https://josm.openstreetmap.de/wiki/TaggingPresets#NameTemplateSyntax, I have not tested this).