Names are not refs vs some names are based on refs

[Minh_Nguyen (Minh Nguyễn)]

@ezekielf

A router looking for <tag indicating that name is based on ref> could then decide to use either name or a constructed name based on ref but would know that using both would be redundant.

So, name:separate=yes?

@ezekielf

Sure, the name can be synthesized but not every data consumer is going to be already synthesizing route names. For those than aren’t, just having a name tag on the way is more straightforward.

This is the current rationale for continuing to tag ref redundantly on each way that belongs to a route relation. For better or worse, that has been a winning argument for a while. But at least in that situation, one could argue that a non-relation-savvy data consumer is left with too little information to serve user needs. By comparison, “Vermont Route 15” adds relatively little information that ref=VT 15 doesn’t already provide. In particular, it communicates systematic, stylistic information about the route network as a whole rather than an individual street.

We can also contrast chain hotel names: a given chain may or may not have a consistent, well-documented standard for combining brand and branch into a name. Besides, the domain of POIs is considerably more open-ended than the domain of route networks. Similarly, if a town does prepend or append a direction, as in the cases I brought up, then I favor maintaining the fully qualified name in name. After all, we have no established alternative for storing these directionals, and the difference between a prefix and suffix can matter a great deal in some places. And tracking these nuances comprehensively would be quite a distraction.