-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Railways should be drawn above roads (when on the same level) #163
Comments
It seems related to the presence of the level_crossing tag? |
Also related to issue #162. |
It's a feature of the z-ordering calculations in osm2pgsql. https://github.com/openstreetmap/osm2pgsql/blob/master/tagtransform.c I main intention of the z-ordering of the roads is to ensure that major roads are drawn after minor roads, so that the fills look OK. The bridges and tunnels aspects of the calculation are less important, since we've now ended up handling the I think the value of "5" for railways is based on relative importance - at medium zooms, say, you don't want major roads obscured by railways, but railways are more important than minor roads. Is there an inherent reason for railways to be drawn over all roads? Are they more important? Or is it just an artifact of us having thin railways and fat roads? |
I see. I think you are right. Railways aren't inherently more important than roads. But on the other hand we have tramways which are always drawn above roads, so there is at least a little bit of inconsistency here… |
Rail hiding under road is causing major problem with bridges (there was an example: https://github-camo.global.ssl.fastly.net/bb7c879693194e95b9f663c07e381d800e9b6caa/687474703a2f2f632e74696c652e6f70656e7374726565746d61702e6f72672f31342f383730352f353830352e706e67 ), as on some zoom levels road is wider than bridge, what makes necessary to set layers for railway to keep it rendered above. Also, some major roads have level crossings with railways - this design style hides it. As major roads are wide current style may hide railway that is constructed along major road. As railways are thin drawing it on top may be better also in this situation. |
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * gravitystorm#462 (Move rendering order road types from osm2pgsql to our SQL queries) * gravitystorm#163 (Railways are now drawn above roads) * gravitystorm#167 (Tramway layering issues) * gravitystorm#168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * gravitystorm#462 (Move rendering order road types from osm2pgsql to our SQL queries) * gravitystorm#163 (Railways are now drawn above roads) * gravitystorm#167 (Tramway layering issues) * gravitystorm#168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * gravitystorm#462 (Move rendering order road types from osm2pgsql to our SQL queries) * gravitystorm#163 (Railways are now drawn above roads) * gravitystorm#167 (Tramway layering issues) * gravitystorm#168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * gravitystorm#462 (Move rendering order road types from osm2pgsql to our SQL queries) * gravitystorm#163 (Railways are now drawn above roads) * gravitystorm#167 (Tramway layering issues) * gravitystorm#168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * gravitystorm#462 (Move rendering order road types from osm2pgsql to our SQL queries) * gravitystorm#163 (Railways are now drawn above roads) * gravitystorm#167 (Tramway layering issues) * gravitystorm#168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
Resolved by #626. |
Confirmed as solved. |
Right now railways are not always drawn above streets, like here:
Here is an example where it works:
(the road and railway ways have neither the layer nor bridge/tunnel tags.)
The text was updated successfully, but these errors were encountered: