I have just added some text to the wiki with my understanding of how to map roads that change name and/or highway classification at a dual carriageway intersection. Can someone more knowledgeable please review this for accuracy of facts and consensus on opinions? I’m particularly interested in whether other mappers would consider it legitimate for me to split off a way section internal to a dual carriageway intersection in order to remove the name and produce better directions in routers that don’t have smart enough heuristics to ignore the names of such sections (see the wiki for further explanation).
Thanks for any attention. As a relatively junior contributor with limited time to spend, I’m still trying to learn how it’s most useful to allocate my effort between just implementing what I believe is right and seeking community feedback.
Thanks for bringing this up. I think your change looks good. I think leaving the inner way unnamed is the most sensible solution. I would also tag noname=yes and consider inventing a new tag like noname:reason=link to reduce the likelihood of a name being re-added in the future.
For all intensive porpoises () it is. Admittedly though a not-very-savvy router might tell you to go straight on B Road, then turn left onto A Road, that I won’t deny.
That’s not really the subject of the conversation though, is it? In such a case I’m sure I’ve picked one or the other of B and C for the little segments in the middle, but if they’re both single carriageways I’ve also split the little way in the middle and named each half the respective B Road and C Road.
(Not arguing that that’s the best way, just providing examples.)
I definitely wanted to include the case where B-road or C-road is a single carriageway in my question; I can think of plenty of examples near where I live. I updated the wiki to clarify this.
Which way around do you mean? If the inner B-road is adjacent to the outer B-road (segment e in the original wiki image), this does not solve the routing problem. If the inner B-road is adjacent to the outer C-road (segment g), so that the names along the road go “B, C, B, C”, that probably solves the problem but in my view has clearly crossed the line into mis-tagging for the router.
I’m still not sure how the community would respond to me re-tagging substantial numbers of intersections in my area. I may do a few as a trial and then seek more input. However, first I tested whether OsmAnd would give me the correct directions if I remove the name from the inner segment (using a locally edited OSM file, not uploaded), and I could not get it to work: the directions had no road name at all for the turn. Since OsmAnd is the router I care about most, I’ll want to get this sorted out before I upload any changes so I know my changes are actually fixing the problem. I’ll ask in the appropriate place on the OsmAnd project when I have time.
To the extent that we ultimately decide to work around the problem on the data side rather than the router side, I agree it makes sense to add noname=yes (assuming that does not break anything with the routers) and a new tag identifying the reason. I’d propose the wording noname:reason=change_at_junction because it’s more descriptive and avoids confusion with highway=*_link. Then I can create a wiki page for the new tag so anyone who sees the tag can easily go to the wiki and understand what’s going on.
Method 1 does not solve the problem because the route “b-p2-p1-e” still says “turn left on C-Road” based on p2. Method 2 probably solves the problem but is mis-tagging for the router. If neither of these is what you meant, can you please provide a diagram?
For completeness, another possible method for the single carriageway case (call it Method 3) is to use name:forward and name:backward. In the original diagram in the wiki, assuming the direction of OSM way p is upward, it would have name:forward=B-Road and name:backward=C-Road. This is probably the truest adaptation of hoserab’s original method to the single carriageway case. To me, it feels like a crutch but not outright mis-tagging. It has the advantage that routers that automatically check for :forward or :backward variants of all the tags they use will get the right answer without needing any handling specific to names or dual carriageway intersections. However, I don’t know if any popular routers actually fall into that category.
I found an existing example of this method on the published map for testing. GraphHopper gives me the ref (MD 222), I imagine because it thinks there is no name. OsmAnd gives me the correct name (Perryville Road), but I imagine that’s coming from the lookahead logic rather than the name:forward.
Speaking from experience, a router will have a much easier time eliding “10m on short unnamed road → Frog Street” than “10m on Cow Street → Frog Street”. The latter case is functionally indistinguishable from a short street which actually is signposted Cow Street.
Unfortunately this could still fail for the case of turning left from C Road onto A Road where A Road is a dual carriageway (g -> p -> aon the diagram), giving an incorrect “straight onto B Road for 5 metres” instruction because you will travel forward on the p way
junction=intersection is supported by AB Streets tools (Street Explorer, Lanes Editor). The implicit reasoning should be good enough that it’s not a must to explain this.
I’m losing interest in working toward a general solution for name changes at dual carriageway intersections at this time, but I’ll write up the rest of what I’ve learned so far.
I tracked down the OsmAnd bug, and it only occurs when the route destination lies in the middle of the first OSM way departing the intersection, which is uncommon outside the artificial examples I used to test the handling of dual carriageway intersections. Oh well.
Examples for testing on the published map as of 2025-06-16 (because testing custom OSM files in a large number of routers is, unfortunately, painful):
So it looks like OSRM and Valhalla always look ahead; OsmAnd looks ahead only if the internal way segment is unnamed; and GraphHopper always uses the internal way segment. (My guess is GraphHopper hasn’t considered the issue at all. Does anyone want to submit a report?) If we just start removing names from internal way segments, then GraphHopper will show no name instead of the wrong name; I’m not sure whether that’s an improvement from the user’s point of view. And even if GraphHopper gets fixed, who knows how many other naive routers are out there.
) it is. Admittedly though a not-very-savvy router might tell you to go straight on B Road, then turn left onto A Road, that I won’t deny.
