opened
pitdicker
username_0
Changes proposed in this pull request:
- Don't render boardwalk as bridge at z14 and z15.

Currently a path with the tags `bridge=boardwalk` and `highway=path` stands out almost as prominently as secondary roads at zoom 14. At zoom 15 it still catches my eye a bit more than a tertiary road. This seems inappropriate for a footway.

I propose to render it as a `highway=path` at zoom 14 and 15, and as before like a bridge at zoom 16 and up.

Test rendering with links to the example places:
https://www.openstreetmap.org/#map=14/52.0113/4.6852

Before
![oud](https://user-images.githubusercontent.com/6255050/92961028-e1cb5300-f46e-11ea-9f97-28fc7d7596d6.jpg)

After
![nieuw](https://user-images.githubusercontent.com/6255050/92961041-e4c64380-f46e-11ea-98f0-43f74bb8a921.jpg)
Don't render boardwalk as bridge at z14 and z15
issue
created
imagico
username_1
I am not sure if this is a good idea.  You are rendering these paths as bridges on the SQL level but then special casing them to be displayed as normal paths on the MSS level at z14/15.  That is complex and confusing for those trying to understand the code (which is already extremely complicated for the roads rendering as is).

If we decide we want this feature i think i would prefer to either modify the bridge condition (which would introduce a zoom level condition in SQL which we have not done so far) or to render bridge=boardwalk not in the bridge layers but as a normal path at all zoom levels and with a dedicated line signature at z16+ matching that of bridges.
comment
created
pitdicker
username_0
I agree it is not perfect. The current rules are basically rendering something with the importance of a way with the extra attention of a bridge. This is my first time touching SQL queries, but I was thinking in the same direction that it could be better to change the bridge condition. If you agree this is worth solving, I'll try out your second suggestion. It seems the cleanest.
comment
created
pitdicker
username_0
Sorry for not making any progress here. I don't know how to make the SQL query take the zoom level in account. And the second option also seems to become more complex.

As I understand it, a bridge is rendered on two layers. One for the bridge casing, and one for the line on top. If you need the bridge casing layer for rendering a boardwalk, you might as well keep selecting it from the database as a bridge.

So I think the current PR is the least invasive change. But as you say, the roads stylesheet is already very complicated... But I would like to see this small issue fixed.
comment
created
imagico
username_1
The second variant is probably the simpler and less controversial variant but it still requires some familiarity with the road rendering to implement a bridge like design in the normal road layers.
comment
created
pitdicker
username_0
Ad an update on this PR: I have neglected, but not forgotten in. A year ago I tried the second option but didn't feel like what I ended up with was clean enough to be acceptable. I have lost that branch since then...

My current plan is to work on the complexity of the road layers, and revisit the boardwalks when there is some progress on that.
comment