Names are not refs vs some names are based on refs

[Baloo_Uriza]

Try the tagging mailing list archives.

[Minh_Nguyen (Minh Nguyễn)]

@ezekielf

I agree. But I take it you don’t consider a street name to be sufficiently adapted if a town doesn’t use directional prefixes or suffixes? If so, why not? To me it seems no different. The town has simply chosen to use the same name that also refers to the route as a whole.

As I’ve said, a bare route number can function as a name. Even “McDonald’s Drive-Through” or “Unnamed Alley” can stand in for a road name in routing instructions and perhaps geocoding results too. Of course, “Vermont Route 15” is more than that – it’s apparently a bona fide name for local addressing purposes. I just don’t think it should be indistinguishable from a more developed name when looking at OSM data in isolation without local context. Anything that requires parsing a string looks a lot less effective from my perspective than anything that requires concatenation.

@ezekielf

Which name tag to use for the sidewalk (name , street:name , is_sidepath:of:name , or something else) is a whole other discussion.

If we rely on a tag to indicate that the name is fungible compared to the available route metadata, then something akin to street:name would be consistent with how ref or route_ref can duplicate the information on a route relation, adding a marginal amount of information on top. It would basically be the longer version of a way ref. Also note how street:name would replace name, not complement it. At that point, your suggestion of a clarifying key would be almost indistinguishable from @Baloo_Uriza’s suggestion of addr:street, though I don’t know if the latter would have any side effects in existing software.

[ezekielf (Zeke Farwell)]

Interestingly, I recently found myself on the other side of a similar naming disagreement. I had noticed some buildings on the University of Vermont Campus tagged with name values like 70 South Williams Street and 481 Main Street. Since these buildings also already had addr:housenumber and addr:street tags with the same information, I figured this was just redundant information that could be removed. However another local mapper commented on my changeset to express disagreement with the removal, feeling that the addresses functioned as names within the campus community. I ended up reverting my changes in deference to his knowledge of the campus. Clearly it can be difficult to tell what exactly is and is not a name.

[Minh_Nguyen (Minh Nguyễn)]

This is sometimes a point of disagreement regarding the names of urban apartment buildings and high-rise office buildings. At least in those cases, it’s essentially the name of a business, which wouldn’t necessarily be subject to all our rules about names. The owner could have chosen to call it “70 South Williams Street”, “70 South Williams”, “70 Williams”, “70 South”, “The Seventy”, or “The Building at 70 South Williams Street”.

Even though all these names communicate the address in whole or in part, none is so obvious that we could presume it as the name based on any general criterion. Moreover, in the less likely event that the name needs translation, it wouldn’t necessarily be a rote translation. A data consumer that would normally abbreviate words in street names might not abbreviate one of these names so aggressively. This goes back to the point about idiosyncrasy:

@ZeLonewolf

If the constructed is unique or special for a particular way, that gives a stronger argument for using name tag. If it’s purely algorithmic, that’s a strong argument for omitting it. If the construction differs in dfferent usages, that’s also a strong argument for omitting it - it lets the data consumer decide how to do the construction.

For example, if Vermont State Route 15 were called “Ye Olde Vermont Route 15” on a certain stretch in the historic part of town, I’d gladly accept the argument that we’re looking at a “real” name and not a constructed one.