Change z-order of ways connecting at a shared node?

[PeterAnderton]

I originally raised the following issue in the general OSM Help, but was advised to re-raise it here as ultimately it is a rendering issue. Essentially it appears to be a more-generalised case of the specific issue raised in #2604.

I needed to add a branching side road to an existing road, so first split the existing road at a new node and then drew in the new side road, starting from this new node. Since all three links sharing this node are one-way, the original road now contributes one inbound link and one outbound link, and the new side road is now a second outbound link.

The original existing road was coded as a Trunk road (orange in colour), and the new side road I added is coded as Minor (white in colour). The problem is that, since the new side road forks off at a shallow angle (as in reality, of course), there is an element of overlap between the white side road and the orange trunk road until the point where they have fully diverged. This wouldn't be a problem, except that the new white minor road appears on top of the existing orange trunk road where they overlap, and to me this just looks wrong; it would look so much better if the orange trunk road appeared instead on top of the white minor road at the shared node.

The offending node can be seen here: [http://www.openstreetmap.org/#map=19/52.53622/-0.30157]. Interestingly, the same node renders correctly in the Humanitarian Layer, and even in the Standard Layer the shared nodes for other new minor links exiting and entering the main roundabout on its southern arc are correctly rendered, yet these were created in exactly the same way.

Other shared nodes in the surrounding area all seem to be rendered correctly; the general rule-of-thumb appears to be that links with a common road type (trunk, primary, minor, etc.) are rendered on top of links with a different road type at a shared node. For example, where the existing trunk (orange) slip road enters the roundabout, it is correctly rendered below the two links that make up the circulating carriageway of the roundabout itself - even though those two links are coded as primary - presumably because they represent the continuous common road type, whereas the trunk slip road is the odd one out at their shared node.

In summary, therefore, is there any way to specify explicitly the relative z-order of lines connecting at a shared node whilst editing, and thus dictate which line should be rendered on top where they overlap? If not, and indeed regardless, why has this particular node been rendered the way it has in the Standard Layer, with the minor road on top?

[sommerluk]

Thanks for this issue report. The report is well written and explains detailed what’s the problem. Sorry for long waiting time before we have answered.

is there any way to specify explicitly the relative z-order of lines connecting at a shared node whilst editing, and thus dictate which line should be rendered on top where they overlap?

No. Our rendering style determined the z-order basically from the highway tag. There is no explicit z-order tag that we support, because we want to avoid taggging for the renderer.

why has this particular node been rendered the way it has in the Standard Layer, with the minor road on top?

In short: Otherwise, a trunk_link that branches from an unclassified road would be rendered above in other situations, and that’s not what we want. The use case you describe in your issue report is less common than the one we want to avoid. The tickets #678 and #266 contain further explications. Therefore I’m closing this issue. Nevertheless thank you for your detailed report!

[mboeringa]

There is also an easy solution to this: set either the primary_link road to an explicit layer=1, or the highway=unclassified to layer=-1.

The layer key was introduced to exactly solve these kind of ambiguous renderings, not just to define bridges or tunnels (which already have their own tags bridge/tunnel=yes). The layer key simply sets a relative order for the stacked rendering.

If needed to avoid other unwanted side effects of setting the layer key, you can cut up a line segment in two, to avoid setting the layer tag for the entire length of the original way, and only apply it where it is needed. Yes, this may create a kind of "artificial" break, but that is largely inconsequential and remember that cutting up ways is already necessary for all kinds of other reasons (changes in maxspeed etc.), so a truly minor issue.