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.

Sign up for GitHub

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

Jump to bottom

Link road inconsistencies #168

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

Link road inconsistencies #168

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

Comments

@tyrasd
Copy link
Contributor

tyrasd commented Sep 16, 2013

  • labels on primary_link have white halo while labels of primaries don't
  • other road types (e.g. footways, cycleways, etc.) are drawn above primary_links while they aren't on primaries.

primary_link

I'm not sure if this also applies to other *_link roads, but I'd guess so.
@mrwojo mrwojo mentioned this issue Dec 11, 2013
Merged
@matthijsmelissen matthijsmelissen mentioned this issue Feb 9, 2014
Closed
@matthijsmelissen
Copy link
Collaborator

Thank you for reporting and sorry for the lack of feedback. The issue is not so trivial. I will look at it, though.

@matthijsmelissen matthijsmelissen mentioned this issue Mar 14, 2014
Closed
@matthijsmelissen
Copy link
Collaborator

See also the following issue on trac:

https://trac.openstreetmap.org/ticket/3247 (this issue also holds for links versus proposed roads)

@matthijsmelissen matthijsmelissen mentioned this issue May 19, 2014
Closed
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Jun 12, 2014
@matthijsmelissen
Move control over road rendering order to SQL
3135148 
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 matthijsmelissen mentioned this issue Jun 12, 2014
Merged
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Jul 10, 2014
@matthijsmelissen
Move control over road rendering order to SQL
0212aea 
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
Move control over road rendering order to SQL
8a50c19 
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
@matthijsmelissen
Move control over road rendering order to SQL
db84b2b 
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
@matthijsmelissen
Move control over road rendering order to SQL
1102359 
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.

Map link

@openstreetmap-trac openstreetmap-trac mentioned this issue Jul 23, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug cartography roads
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tyrasd @matthijsmelissen