Skip to content
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

Closed
2 tasks done
tyrasd opened this issue Sep 16, 2013 · 4 comments
Closed
2 tasks done

Tramway layering issues #167

tyrasd opened this issue Sep 16, 2013 · 4 comments
Labels

Comments

@tyrasd
Copy link
Contributor

tyrasd commented Sep 16, 2013

  • Tramways are drawn above bridges

  • Underground tramsways not drawn when the tunnel is also a highway


    way/192602347

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
@matkoniecz
Copy link
Contributor

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
@matthijsmelissen
Copy link
Collaborator

Resolved by #626.

@matthijsmelissen
Copy link
Collaborator

First issue confirmed as solved. Second issue is duplicate with #529.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants