As far as I am aware, it is recommended to add the road name to each segment of the road if it spans across split segments.
However, this may lead to rendering issues and tagging errors, as any name changes must be reflected on all relevant segments of the road.
While relations are commonly used for signed routes to combine multiple road sections, I am curious why using a relation to consolidate identical names is not a commonly adopted practice?
There’s a type=street relation too. Use it frequenbtly for multi segment streets of same name
Splitting of roads is very common and needed to apply different road features or route relations along the way. If short road segments result in rendering issues, the renderer should account for that. Relations of type=street are used but regarded as kind of uncommon (at least in my local community).
Kind of funny you say that. ;o)
I do not recommend type=street relations to leave out name from the various road segments of the same road. They are very uncommon and hence software support for this kind of construct is very bad:
There are roughly 100 million roads in OSM, about 50 million have a name set. In contrast, there are just 20 thousand type=street relations.
Anyway, the wiki page for type=street does not actually suggest that the street name could be left out from the individual street segments and it doesn’t seem to have been suggested here either. So, I figure you could use the relation, but it is not a surrogate to also adding the name on the individual road segments.
So why does that relation exist at all? I think the idea has been to group also things like separately mapped bicycle paths and sidewalks into the same relation to make it easier for data consumers to know what’s what. But to be really useful (and actually supported/used by software), this would have to be done somewhat comprehensively, and that hasn’t happened. Also, it makes editing an area with such relations more complex, introducing the potential for error: For example if someone adds a separately mapped bicycle path but doesn’t add it also to the relation.
For this reason, I find approaches that group elements associated to one street by area more promising. If it is defined by area, you do not have this maintenance problem of potentially introducing error by forgetting to add new elements also to the relation. Also, to know the actual area geometry of a road + footway + parkings etc… is useful for other use cases, too. area:highway is one such attempt, not sure if there are others and not sure if it solves all the issues associated with this topic.
That is oldish stuff that is not maintained anymore 
Old and unmaintained? Hmm, at risk of being called out to encourage vandalism:
If you happen upon such a relation that is erroneous (e.g. new elements of the road haven’t been added to it or there are even some segments in the middle missing) and apparently noone has been maintaining it for quite a while, I find it okay to remove it.
In my opinion, erroneous data is in most cases worse than no data. And if there is noone left (willing) to maintain it, it should rather be removed.
Same with for example opening hours: If you find out that the recorded opening hours are wrong but for some reason or other do not have time to correct them, it’s better to remove them than not touching them.
Yes, actually this is a good point to start with it. I will address this on our next monthly community meeting before taking any action. Looking at type=street | Tags | OpenStreetMap Taginfo Bremen seems to be one of the few “hotspots” on the planet concerning this type of relation.
Updating the name tag on multiple ways is easier than maintaining relations. Relations also open up the possibility of overlapping names that don’t reflect reality.
The rendering issues are better off handled by fixing the render.
Looking at Tags | OpenStreetMap Taginfo Bremen seems to be one of the few “hotspots” on the planet concerning this type of relation.
not sure something has changed, but taginfo still has a disclaimer that the maps show only nodes and ways but not relations
Oh yes, that’s a new one to me. Thank you!
[edit: still a hotspot though 
]
While it may be a (discouraging) disclaimer, I did test some nodes in the Overpass view and they all opened up as linked to a type=street relation, so I’m happy.
, and BTW 20,000 is 27,000 such relations and the one in my regular mapping area I’m happy to maintain, to include any mapped sidewalks and cycle tracks, naming them like the street they run aside by as that seems to make it easier for routers I read in me early active mapping days. When it’s broken we(me) repair it…
Same question here, the question doesn’t seem resolved so I’ll bump this up.
I get that type=street doesn’t have a lot of support currently, but if we ignore this for the sake of the argument (because support depends on tag popularity), wouldn’t it make more intuitive sense to use relations for split segment streets? The opposite seems to go against One feature, one OSM element - OpenStreetMap Wiki. I also don’t see why type=street should be any different from something like type=waterway.
Right now I’ll keep duplicating street names for the sake of support, but isn’t this a relevant question to bring up in local OSM chapters?