-
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
Tramway layering issues #167
Labels
Comments
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
Jun 12, 2014
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
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
Jul 10, 2014
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
matthijsmelissen
pushed a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
Jul 10, 2014
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
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
Jul 11, 2014
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
matthijsmelissen
added a commit
to matthijsmelissen/openstreetmap-carto
that referenced
this issue
Aug 1, 2014
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. |
First issue confirmed as solved. Second issue is duplicate with #529. |
This was referenced Jul 23, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tramways are drawn above bridges
Underground tramsways not drawn when the tunnel is also a highway
way/192602347
The text was updated successfully, but these errors were encountered: