Move guideways to roads #5057
Move guideways to roads #5057
Conversation
Also tweak to SQL for link roads
Also simplification of selectors
There was a problem hiding this comment.
Not tested yet.
I am fine with adding bus_guideway and busway to the z_order definitions.
Likewise for integrating the bus guideways with the roads, fixing the layering issues and removing coding oddities.
I am not sure if changing the appearance of guideways with the current design is a good idea. I consider this design a dead end - both regarding color and regarding the similarity to railways. The natural choice for the future would be to combine it design wise with the rendering of other bus exclusive roads.
Given that #214 is addressed now it would be possible to work on an overall design paradigm for bus exclusive roads (and possibly other access restriction with exception variants) - removing the need to invest into maintaining the old bus guideway design.
But this is just my personal idea of what i would consider the most effective approach long term. And the lack of a clear tagging consensus on bus exclusive roads makes that idea somewhat difficult to pursue of course. And also the political investment of certain loud parts of the OSM community in this matter has also turned this into a bit of a minefield.
Bottom line: I don't have a substantial objection against the design adjustments per se but i am a bit wary about this sending the wrong message (to developers as well as map users) of re-emphasized endorsement of the legacy rendering of bus_guideway.
Anyone who wants to work on a comprehensive design approach to bus exclusive roads - as a follow-up to #4952 and in pursuit of the goals of the project and with the ambition to develop a good holistic design - has my full support.
openstreetmap-carto-flex.lua
Outdated
| @@ -400,6 +400,8 @@ local roads_info = { | |||
| primary_link = { z = 220, roads = true }, | |||
| secondary_link = { z = 210, roads = true }, | |||
| tertiary_link = { z = 200, roads = false }, | |||
| busway = {z = 190, roads = false}, | |||
There was a problem hiding this comment.
Whitespace inconsistency here
Fix whitespace Remove width increase for Z17+
This certainly wasn't intended to endorse the current design - merely split off the technical aspects of creating a new highway render from the design ones. I have removed the widening from Z17+ so there is less chance of misinterpretation.
Indeed. I think a holistic design to |
Fixes #3581
Changes proposed in this pull request:
As part of #5041, the
guidewayslayer containinghighway=bus_guidewayshould be moved into the roads layer. Accepting that the rendering used forbus_guidewayis sub-optimal, this PR has the limited goals of:highway=bus_guidewayandhighway=buswayto the highway types in the osm2pgsql import, which will facilitate a future coherent approach to rendering both features.It doesn't currently add a
namerender (in contrast to the other features of the roads layers).It assumes that the
highway=bus_guidewayrendering will be narrower/lower priority thanhighway=busway. Their priority is below the "standard" road types, but abovehighway=service.Test rendering with links to the example places:
Before
Bus guideway in middle of dual carriageway at Z14:
After
Note how guideway is currently drawn of top of roads. In the revised render, the lower priority guideway is "hidden" by the overlapping dual carriageways (expected behaviour)
Same location at Z18:
Before:
After:
Note the better join, the oneway arrow indicating direction of guideway and the slightly thicker width.
Bridges/tunnels involving guideways are very rare. The artificial legend shows the rendering proposed for tunnel, bridge and normal variants respectively, and also shows that
layer=1applied to the bridge and "normal" variants works as expected:Note that the highway prioritisation will only work correctly after a database import.