Ok, so both are easy. What are the remaining arguments for making up a ”name but not name” tag for one specific kind of way?
I’m not sure why you would characterize street:name as meaning “name but not a name”. It’s just as much a name as any of the other many different keys we use for names. It just means specifically the street name in the same way bridge:name and tunnel:name are for bridge names and tunnel names specifically. It’s also not used just for one specific kind of way. Although it was originally conceived for sidewalks, it is now also being used on streetside parking objects to specify the street they are a part of.
My argument for street:name on sidewalks is this:
- A street name represents a whole street corridor, not specifically the carriageway part of the street, the sidewalk part of the street, or any other part.
nameis for the primary name of the tagged feature. Thusname={Street Name}belongs on an object that represents the street as a whole.- A sidewalk way represents the sidewalk part of the street, not the street as a whole, thus a different tag meaning “this is the name of the street this object is a part of” makes sense.
street:name={Street Name}fits that meaning nicely.
As far as I can see, the same argument applies to side carriageways or secondary carriageways intended for cars (for example).
Thus, I am looking forward to *:name being adopted by data users, so that it can be suggested to retag such secondary carriageways to use *:name rather than name.
If street relations aren’t happening, why would we need to use tags that only make sense in street relations? Especially when the other ways this would apply to are not using those tags.
Indeed. Plus @ezekielf makes a pretty good point for using street-relations…
I’d just like to see sensible implementations of that…
It’s sort-of doable (with major caveats) in a number of common toolchains, but it’d be a major PITA (“want to consume OSM data? First you need to stand on one leg and play Yakety Sax really fast on the penny whistle”).