|
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. Is there any way I can explicitly specify the relative z-order of lines connecting at a shared node, and thus dictate which line is rendered on top where they overlap? Yes, I am very new to all this!
showing 5 of 7
show 2 more comments
|
|
Basically, I don't think this is how you fix this issue. OSM might look like it's a map, but it's really a geographic database. So the important thing is to put correct data into the database, which you've done. 🙂 It's up to people who use it to use it well. So the people who make the map on osm.org are responsible for how it's displayed, such as making sure that things are displayed correctly. And this looks like a bug in how they display things. So I suggest you contribute to the mapstyle by alerting them to this bug, maybe by opening an issue. 3
Actually, I believe that the decision to render all non-links over links is a deliberate decision in this map style - see https://github.com/gravitystorm/openstreetmap-carto/issues/266 and the links from there. However, it'd be really simple to create your own maps that don't do that based on a version of that map style. That style assigns z_order at https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua#L180 , and there are "set up your own copy of it" instructions at https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ and https://github.com/gravitystorm/openstreetmap-carto/blob/master/INSTALL.md .
(29 Jan '18, 11:18)
SomeoneElse ♦
2
I'd like to add that the new road should no be tagged as unclassified but as trunk_link in my eyes. It's still a link from Fletton Parkway onto that southbound unclassified road. Then the standard map style's way to render links and no-links would make sense again.
(02 Feb '18, 12:21)
TZorn
|
A link from OpenStreetMap.org so that we too can judge it's appearance.
https://www.openstreetmap.org/#map=18/52.53626/-0.30183
The Humanitarian Layer looks better
https://www.openstreetmap.org/#map=18/52.53640/-0.30174&layers=H
Behold: http://www.openstreetmap.org/#map=19/52.53622/-0.30157
The new minor road is a dedicated slip road off the main slip road, so left-turning traffic can avoid having to stop at the roundabout.
Indeed - apart from the different colours, the Humanitarian Layer is rendered exactly as I would have liked the Standard Layer to be, with the trunk links on top of the minor link.
Oddly enough, I also added the minor links exiting and entering the main roundabout on its southern arc, and in exactly the same way as I added the new slip road, yet these shared nodes are correctly rendered.
Surely it isn't the case that the z-order of links as rendered at a shared node is entirely random? If that were true, OpenStreetMap would look awful, but clearly it doesn't, so there must be some sort of mechanism at work that dictates this relative z-order for rendering purposes. So my original question can essentially be restated as: what is this mechanism, and how can I influence it where the default results are unsatisfactory?
https://wiki.openstreetmap.org/wiki/Standard_tile_layer has info on the rendering of the 'standard layer' and a link near the top to github....openstreetmap-carto
It is suggested that you raise the issue there.
As advised by nevw, I have moved this issue to the openstreetmap-carto forum on github. It now appears there as Issue #3040 (https://github.com/gravitystorm/openstreetmap-carto/issues/3040).
I think this road is a link road not a minor road. https://wiki.openstreetmap.org/wiki/Map_Features#Link_roads
Incidentally, there's no need to split the original way just because you're adding a new way that connects to it.