Show ref in the name of route relations

[k-yle]

Closes #8559, cc @1ec5

Editing bus routes with similar names is very confusing. Especially when the ref is what you use conversationally, not the name.

This PR changes utilDisplayName to use both the name and the ref tag, but only for routes.

Before	After

[papac25]

i just told

[papac25]

not ready to merge

[k-yle]

hello @papac25, could you please explain why this is "not ready to merge"?

[HermanLeeZh]

Most of bus routes have already have "ref" in the name tag. It is a needless duplication, I think.

[HermanLeeZh]

@k-yle

[k-yle]

Most of bus routes have already have "ref" in the name tag. It is a needless duplication, I think.

There are some mappers who insist that the name tag is for the real name, and isn't meant to contain the ref. If that advice is wrong or out-of-date I'm happy to close this PR and update my local bus routes instead.

@HermanLeeZh Is there a recommended format for the name when it contains the ref? name=[50X] Eastern Connector or name=(50X) Eastern Connector or something else?

[HermanLeeZh]

Most of bus routes have already have "ref" in the name tag. It is a needless duplication, I think.

There are some mappers who insist that the name tag is for the real name, and isn't meant to contain the ref. If that advice is wrong or out-of-date I'm happy to close this PR and update my local bus routes instead.

@HermanLeeZh Is there a recommended format for the name when it contains the ref? name=[50X] Eastern Connector or name=(50X) Eastern Connector or something else?

@k-yle Maybe you can look up this wiki page. Here provide a
recommended format name=<type of transport><reference number>: <from> → <to> eg :Bus 201: Uitikon Waldegg, Bahnhof → Uitikon, Wängi and Trolleybus B103: Daguanyuan -> Yan Spring. This change of display can mislead mappers.

[LaoshuBaby]

Yes, I agree with @HermanLeeZh 's opinion, if we follow PTv2 name style, the display will make <ref> duplicate.

The <ref>+<name> display is our compromise to other name schema.

I suggest this new display schema should detect whether public_transport:version is defined before apply the display schema, if the value is 2, it means the relation follow the wiki page.

---

BTW, the tagging schema truly have a lot of version, such as PTv1, PTv2, Oxomoa schema, Zverik schema

The name style of Zverik schema are the same as PTv2

[HermanLeeZh]

Most of relations follow the PTv2 now.page

[k-yle]

Great, thanks @HermanLeeZh and @LaoshuBaby ! I think we can close this PR then. I'll send this link to anyone who complains about sticking the ref and destinations in the name tag.

[1ec5]

Did you all miss the footnote on that wiki page? 😄 The strict name format was indeed part of the original proposal, but it is now widely discredited as a prominent example of “tagging for the editor”, as seen in the links I listed in this discussion. Reducing iD’s dependency on the legacy name format was also the original motivation for #8276.

@k-yle, if you’re still interested in pushing this change to completion, maybe there’s a way to accommodate the legacy format in the interim, while other editors sort out their relation support. For example, we could make it so that the ref only appears for disambiguation purposes if the name doesn’t already contain it. That would avoid the potential confusion of a duplicated number and avoid unduly influencing mapper behavior.

[HermanLeeZh]

Did you all miss the footnote on that wiki page? 😄 The strict name format was indeed part of the original proposal, but it is now widely discredited as a prominent example of “tagging for the editor”, as seen in the links I listed in this discussion. Reducing iD’s dependency on the legacy name format was also the original motivation for #8276.

@k-yle, if you’re still interested in pushing this change to completion, maybe there’s a way to accommodate the legacy format in the interim, while other editors sort out their relation support. For example, we could make it so that the ref only appears for disambiguation purposes if the name doesn’t already contain it. That would avoid the potential confusion of a duplicated number and avoid unduly influencing mapper behavior.

@1ec5 Emm, I have noticed the footnote. I agree. I find the state is that most routes have ref on name=, at least in big cities. We should have a recommended format for tagging.

[LaoshuBaby]

I find the state is that most routes have ref on name=, at least in big cities.

The main idea of that footnote (and the email) is we are wrong use the name=* tag to do a dirty information board. (But the situation will last for long time until we meet with a global consensus of PT name=* tagging and all major editor use a new method display combined value of ref=*, from=*, to=*. I think, it will be long future, it looks impossible.)

Like @1ec5 said in #8276 's Rationale part:

Better editor support for the structured data will mitigate the pain that mappers might experience from deprecating the naming convention.

---

For @HermanLeeZh :

We should have a recommended format for tagging.

If one day most data have comprehensive metadata tag and our major data consumer started to use structured data first, I agree with the assembled name like Bus 88: Beijing Station -> Tiananmen Square(and its all localized varient) can be deprecated because we already have many assembled-name schema, and looks like many country don't follow it.

#8276 (comment)

This situation is because the assembled-name schema haven't allow a ref, the best way is to deprecated current naming process , and let all editor changed to combine different part of metadata in a specific schema (whatever it is).

It need we unite all community to review all current relation, and all editor such as JOSM, iD, Potlatch and so on announced they change to this way. It is so hard so I think this is impossible

So, I retreat to the second best, I personally encourage and strongly support naming name=* according to a strict (but allow keyword localization) PTv2 schema, which at least takes away the confusion (in the comment I shown above) and provides a way to display important information such as from/to/ref at the same time, and no matter how long the name is, ref is easy to see and distinguish.

Thanks you all for read this.

:)

[1ec5]

It is not impossible to make editors less reliant on the descriptive name format. It’s circular logic to claim it’s impossible to make this change as a reason to prevent iD from making this change. Coordination is not a bad idea, but @k-yle and I have been very careful not to rush any changes in iD that would lead to relations going unlabeled in JOSM overnight. This PR was only about displaying something more informative when a route happens to be named like it is in the real world.

The descriptive names are purely an editor concern. It’s quite unlikely that any data consumer goes out of their way to parse route numbers, origins, and destinations out of name when they can more easily and reliably get the values from ref, from, and to, respectively.

As important as PTv2 schema may be, it’s even more important to avoid tagging for the renderer editor. The descriptive name format prevents name from being used in the manner it’s used for all other features in OSM, including other kinds of routes. In some places, routes have real names that we couldn’t use name for, and some routes have both common names and official names that we didn’t have enough keys for. That’s a bigger problem for data consumers than any theoretical concern about backwards compatibility.