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

Railways should be drawn above roads (when on the same level) #163

Closed
tyrasd opened this issue Sep 14, 2013 · 9 comments
Closed

Railways should be drawn above roads (when on the same level) #163

tyrasd opened this issue Sep 14, 2013 · 9 comments

Comments

@tyrasd
Copy link
Contributor

tyrasd commented Sep 14, 2013

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.)

@matthijsmelissen
Copy link
Collaborator

It seems related to the presence of the level_crossing tag?

@matthijsmelissen
Copy link
Collaborator

Also related to issue #162.

@tyrasd
Copy link
Contributor Author

tyrasd commented Sep 14, 2013

To me it looks to be induced by road classification: secondaries, primaries, etc. do overlap railways, tertiary and below don't:


@gravitystorm
Copy link
Owner

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 layer tag with separate layers in the stylesheet (long after the osm2pgsql z-order code was written).

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?

@tyrasd
Copy link
Contributor Author

tyrasd commented Sep 16, 2013

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…

@matkoniecz
Copy link
Contributor

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.

@CloCkWeRX
Copy link
Contributor

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

Resolved by #626.

@matthijsmelissen
Copy link
Collaborator

Confirmed as solved.

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

No branches or pull requests

5 participants