Move highway areas below all linear road types

[matthijsmelissen]

This PR moves highway areas below all linear road types (resolves #3281).

In particular, this change has the following effects:

• Render highway areas below tunnels (resolves Render tunnels above highway areas #529). This prevents the current situation where
  tunnels are invisible if there happens to be a highway area above them.

• Render highway areas below line/area barriers, ferry routes, tourism boundaries, cliffs, landuse-overlay, and turning circles. I think these changes are mainly neutral or positive.

• Render highway areas below line/area barriers linear roads. This is probably the most controversial aspect (but necessary for the other changes). See screenshot below.

• This PR is a necessary condition for merging the roads-casing and roads-fill layers (part of Combine road lines and areas to one layer #2046), which would greatly simplify our code.

• This PR is a necessary condition for rendering buildings above highway area (Building doesn't render on top of highway areas any more #688).

• Promoting linear highways over areas makes life easier for other data consumers, that already tend to have poor support for highway areas. For example:

  • Transport and wikipedia do not render road areas
  • Humanitarian, bicycle, mapbox, streets, OSM bright renders linear roads on top of areas, like in this proposal

[matthijsmelissen]

Render highway areas below line/area barriers. This is probably the most
controversial aspect (but necessary for the other changes). See screenshot
below.

Before:

After:

[imagico]

This would essentially remove all the road polygons from the road layering system and render them as a second landcover layer (after the bridge layer - which makes some sense but also after the water layers, which means water features would still not be rendered above pedestrian areas etc.)

This would be a major strategic decision for this style. Right now we are essentially the lead style in the OSM world in terms of sophistication in interpreting road mapping in OSM - the various flaws in that notwithstanding since almost all other styles are much worse in that regard. Since mappers check their work primarily with our style other styles with equal or less sophistication are usually on the safe side because the data has been evaluated against the more demanding requirements of us already. Giving up the lead role in sophistication of interpretation of the roads data would affect this balance.

OTOH the roads have IMO too much weight in this style overall. And while simplifying how we deal with roads on a technical level does not directly affect the visual weight in the map - on the contrary, your change would significantly increase the visual noise as is, on a strategic level such a change could be a signal to tuning back the weight of roads also in visual design.

My own approach to solving the layering problem with road lines and polygons would be the opposite direction: To merge road lines and polygons as well as casing and fill into a single layer to be able to sort them freely as needed in rendering. Accordingly i would disagree with your statement that

This PR is a necessary condition for merging the roads-casing and roads-fill layers

This would of course not solve the problem of various non-road features not being visible above road polygons - this is something that could be solvable using comp-op technique as discussed for water areas in #3854.

Your change would also prevent any chance of having a consistent layering of bridges and tunnels polygon features in the roads system.

I would also like to point out that

Promoting linear highways over areas makes life easier for other data consumers

is not covered by our current documented goals. The mapper feedback effect of your change would be fairly ambiguous - mappers essentially have the choice between two strategies which both lead to suboptimal visual results in the proposed rendering:

• ending linear roads at the edge of a road polygon (like a pedestrian or a highway=service area) - this is done on the left in your example and leads to a non-natural, undesirable round line end casing line being visible across the area.
• drawing linear roads as virtual connections across the areas. This is probably what is considered desirable by many data users but it is not generally the most accurate representation of reality and the visual feedback does not necessarily favor this. A line being shown where no line exists in reality might appear more negative to many mappers than the round line end casings in the first variant.

Overall the more explicit visual feedback would clearly in a way be an improvement from the current situation where no clear visual feedback is given but it does not really help the mapper much in determining what is the right way to map things.

In total i am undecided on this - i see both advantages and disadvantages - but i think this definitely warrants a thorough consideration and a discussion of our strategic goals w.r.t. roads rendering.

[matthijsmelissen]

@pnorman Could you review this?

[jeisenbe]

I've checked the results of this PR in a few places.

Render highway areas below line/area barriers. This is probably the most controversial aspect (but necessary for the other changes). See screenshot below.

I don't see a line or area barrier feature in the screenshot, just pedestrian roads, residential roads and a service tunnel. What am I missing?

I found this hedge mapped as an area on top of highway area a while back. While I had "fixed" this by changing the pedestrian highway area to a multipolgyon, here's what it would be like if I hadn't come around:

Current rendering

After

I'd consider the new rendering to be poorer feedback, because the hedge area shouldn't be part of the pedestrian area, but it's a minor issue.

Having line barriers over highway areas seems to be a benefit, though I'd still like to find an example of this. A pedestrian plaza could have a short fence or wall or hedge, yet the rest of the surface would be unobstructed and so could be mapped as one area.

The main problem with the new rendering is with highway=pedestrian lines which stop at or cross a highway=pedestrian area. Other highway types which cross a pedestrian area have a subtle difference in the new rendering, because the contrast between the other highway fill color and the pedestrian fill is high, so the presence of the casing is not obvious. But when a highway=pedestrian way crosses an area, it is currently invisible, but would become quite apparent:

Before - grand market, Brussels

After

An alternative might be to try removing the casing for highway=pedestrian or rendering it in the fill color, which would have a similar effect. Tested with poor results.

We could also try to lighten the casing on highway=pedestrian areas: currently it looks like there is a fence or wall around these areas, but this isn't the case.

However, I would like to discuss if this solution is superior:

merge road lines and polygons as well as casing and fill into a single layer to be able to sort them freely as needed in rendering

That sounds like an interesting idea. Has this already been implemented in a different style?

[jeisenbe]

Render highway areas below tunnels (resolves #529). This prevents the current situation where
tunnels are invisible if there happens to be a highway area above them.

Tunnels are invisible under linear road fill, which can be quite wide when there is a dual-carriageway.

Rendering things like subway tunnels over squares and plazas can impair legibility:

After - place fontainas

This PR is a necessary condition for merging the roads-casing and roads-fill layers (part of #2046), which would greatly simplify our code.

It appears this statement may not be totally correct, per @imagico's comment above and the text of #2046 where the plan was to merge roads-casing, highway-area-fill and roads-fill into one layer?

This PR is a necessary condition for rendering buildings above highway area (#688).

This would be good for building=roof but not for other types of buildings, suggesting that solving it would require adding another layer. Is that your thought?

Promoting linear highways over areas makes life easier for other data consumers, that already tend to have poor support for highway areas.

I don't think that this PR would do this. While it would unify our rendering with some others, it may promote removal of highway=pedestrian linear ways from plazas and squares.

[matthijsmelissen]

Render highway areas below line/area barriers.

Not sure how this got there, should be: Render highway areas below linear roads (as seen in the screenshot). Sorry for confusion.

[kocio-pl]

Just the idea: what if we decouple highway=pedestrian outlines from the rest of its elements (like filling or labels) and render the outlines under the areas, and the rest of elements above them?

[jeisenbe]

highway=pedestrian outlines ... under the areas

One of the goals is to make it possible to reduce code complexity. But creating a new layer for highway=pedestrian casing would be counter to that goal.

Another goal was to render some or all buildings over highway-areas - but if highway=pedestrian casing is under these area, they would also be rendered under buildings, leading to poor results at mid-zoom levels. Where the highway=pedestrian rendering is wider than the space between buildings, like on old city centres, the buildings would block parts of the casing where they overlapped.

[jeisenbe]

Here's a place for testing with line barriers on top of a highway=pedestrian area, and service road tunnels under it. But wait, it's actually on top of a building! This appears to be an elevated pedestrian area on a university campus, which connects the upper levels of several buildings. I think there is a swimming pool and sports centre under part of it.

This would be hard to get right: if we start rendering buildings on top of pedestrian areas, the building would render on top, unless we rendering all highway areas, buildings and linear roads based on layer.

https://www.openstreetmap.org/#map=18/53.10729/8.85636
Aerial image:

Before:

After:

• The current view does not show the service road under the western part of the elevated highway=pedestrian area, which is highway=service + covered=yes
• Current view does not show wall barrier to northwest of swimming entrance, but this probably should be excluded from the highway=pedestrian multipolygon. The "after" image renders this and the other walls (around each of the brown areas, and around the one tree), but perhaps it should not.
• Current mapping appears to use highway=footway + bridge=yes to make it easier for routing applications, but this leads to a somewhat misleading rendering.
• Neither "before" or "after" view shows that the circular "holes" in the pedestrian area are tagged with natural=scrub (there are bushes there), since landcover is underneath buildings.

Getting this to render "properly" would require merging landcover, buildings, highway-area and all road layers and then using layer= to set the rendering order for everything.

[jeisenbe]

I tried changing the highway=pedestrian casing to be lighter, or rendering it in the same color as the fill, but I don't think the results are very good:

Bremen, current

After this PR

After this PR, plus highway=pedestrian casing removed
(Actually rendered in same color as fill)

After, lighter highway=pedestrian casing

The lighter casing is less distracting on top of the highway (pedestrian) areas, but now the linear pedestrian roads are slightly harder to follow.

[pnorman]

It might be a couple weeks till I can review this with all my SOTM stuff coming up

[matthijsmelissen]

I made the pedestrian area background slightly brighter now. In my opinion, this works reasonably well both in cases where linear roads end on the area, and where linear roads continue across the area:

[jeisenbe]

I don't think the new pedestrian-area-fill color #ebebf7 is an improvement.

Using a different color for linear highway=pedestrian ways and highway=pedestrian areas makes the ways look more distinct when drawn across a pedestrian square or plaza. But in most cases this is misleading, since in an area tagged highway=pedestrian + area=yes pedestrians can travel freely in many directions.

The new color #ebebf7 is between #dddde8 used for pedestrian-fill and #ededed used for living-street-fill - but when a darker landuse is tagged on the surrounding area (like residential-fill #e0dfdf, or commercial #f2dad9) the new area color appears more similar to living-street-fill:

pedestrian-fill #dddde8 - Lch (88,6,291)
pedestrian-area #ebebf7 - Lch (93,6,291)
living-street-fill #ededed - Lch (94,0) - so the lightness is much closer to living-street-fill

• New area color is in the middle; pedestrian-fill on the left, living-street on the right, background is residential.

The current rendering emphasizes that highway-pedestrian + area=yes is similar to a highway=pedestrian way: it's a wide area used exclusively by pedestrians. Changing the color would lose that.

Comparisons:

Bremen centre, Current rendering:

Previous commit (same color for pedestrian ways and areas):

Latest commit:

I also note that the new area color #ebebf7 is somewhat close to the newer gray colors for parking #eeeeee (which is identical to living-street - just opened an issue about this) and transportation-area (airports and stations) #e9e7e2 - but that's more a problem with those two newer colors.

[jeisenbe]

I recommend against adding this new color

[jeisenbe]

If I'm interpreting the rendering correctly, it looks like the Opencyclemap style deals with this problem by rendering in this order:

1. Pedestrian area and way casing
2. Pedestrian area fill
3. Tunnels, paths etc.
4. Pedestrian way fill
5. Other highway casing / fill etc.

See https://www.openstreetmap.org/#map=19/50.63233/3.06199&layers=C
Or perhaps I'm mistaken? I don't believe that stylesheet is public.

But it might be worth trying this method. The casing of highways would show over highway=pedestrian ways after this, but that might be reasonable, since usually there is something like a curb which prevents motor vehicles from driving straight into pedestrian ways.

Note: this was the idea suggested by @kocio-pl above: #3872 (comment)

[kocio-pl]

Promoting linear highways over areas makes life easier for other data consumers, that already tend to have poor support for highway areas.

After thinking a bit - at the same time it's promoting virtual lines (tagging for routing) instead of real geometry that is visible on the ground.

[kocio-pl]

@imagico

OTOH the roads have IMO too much weight in this style overall.

Could you briefly explain what do you mean here? I think OSM Carto is moderate in this respect and it is a German style that gives them too much weight.

My own approach to solving the layering problem with road lines and polygons would be the opposite direction: To merge road lines and polygons as well as casing and fill into a single layer to be able to sort them freely as needed in rendering.

I also like this solution.

[IgorEliezer]

If I may, I'd like to recommend something: Venice is heavy mapped with pedestrian ways, areas, building passages and bridges. It's interesting to test this proposal there to see the impacts.

[matthijsmelissen]

I also like this solution.

As I stated before, these are perpendicular discussions. In order to resolve #529 and #688, we would still need to render linear roads on top of areas, no matter if we merge linear roads and areas into a single layer or not.

[matthijsmelissen]

If I'm interpreting the rendering correctly, it looks like the Opencyclemap style deals with this problem by rendering in this order:

Yes, I think they do something like that. In #529 (comment), I described the three requirements that are fundamentally mutually inconsistent. OCM violates the 'The casing of roads must be rendered on top of tunnels' principle for pedestrian roads. See https://www.openstreetmap.org/#map=21/49.61187/6.13299&layers=C, where you can see that tunnels are rendered on top of pedestrian roads.

So we can go the OCM way, but that means the tunnel versus pedestrian ordering will be incorrect.

[jeisenbe]

In order to resolve #529 and #688, we would still need to render linear roads on top of areas, no matter if we merge linear roads and areas into a single layer or not.

But if we merge highway lines and polygons, couldn't we also merge man_made=bridge and building=roof polygons into the same layer?

Or do you think all types of building=* should be rendered on top of highway=pedestrian areas? I believe that would not be beneficial, since most buildings (those with walls) should be excluded from pedestrian areas.

[matthijsmelissen]

Even if we merge man_made=bridge and building=roof layers too (without going into the merits of that), it still requires us to solve the area-fill > road-casing > tunnel > area-fill (mutual incompatible) requirements, which this ticket is about.

[jeisenbe]

I'm willing to try this change, but I would like to see if the issues with overlapping highway=pedestrian ways and areas can be improved. The latest commit did not help.

What do you think about using a lighter color for highway=pedestrian casing as in #3872 (comment) or perhaps a slightly different color?

Or the idea by @kocio-pl and OpenCycleMap of rendering highway=pedestrian fill first? (This will not improve things for highway=living_street and highway=residential areas, but those are much less common.)

[imagico]

@matthijsmelissen, @pnorman and myself had a quick chat about this change at SotM. My position is unchanged (i am personally undecided if this is a good idea or not) but i will not block this change if it otherwise finds approval. I will try to summarize a few points i took from the discussion:

• the more explicit rendering of combinations of linear and polygon mapping of highway areas would in principle be in support of the mapper feedback goal of the style - though as discussed different mappers could based on the visual feedback consider different mapping styles as positive. So it is not sure what practical effect such more explicit feedback would have.
• the alternative approach of including the highway polygons in the normal linear road layers would not solve the problem of other features being not visible above the highway polygons.
• so far we have only looked at highway=pedestrian polygons though we render also other highway types when tagged on polygons.
• our main constraint here is the fundamental limitation of our toolchain of the order in which data is queried being directly tied to the order in which things are drawn on the map.

[kocio-pl]

After some more thinking:

• 👍 I support rendering barriers, landuse overlays and cliffs over areas
• 👎 I'm opposed to the general idea of highway areas below linear road types
  • in particular I'm opposed to rendering tunnels above highway areas, but also above buildings (rendering underground waterways looks for me like a proper solution)
• I'm not sure about ferry routes, tourism boundaries and turning circles, I need some real examples to analyze them

Primary reason for this is visual promoting on the ground data, because this is a map, not a routing service. We already support routing data too prominently - there are multiple maps showing lines instead of real geometry, while for example I'm aware of only one service rendering area:highway (see #180), but only for a limited territory (see http://osmapa.pl/w/area/ ).

On the low and medium zoom levels it makes perfect sense to use line model as a simplification, but on high zoom, where highway areas are available, they produce evident artifacts, which we just got used to, even if lines just don't belong to this scale. Current road rendering system is a clever hack around this, which on the one hand is good, since roads are very basic and popular type of map data and it involves even more work to add their shapes, but the downside is we're stuck in the simplified version even when this is possible to show more precise data (mainly in the well mapped cities).

[imagico]

Please keep in mind that this is not about what we'd hypothetically want if there were no technical constraints. Although there might be differences in opinion on that as well it does not really matter because most in that regard is essentially not feasible because it would be very complex to implement and maintain and very inefficient in rendering.

This is about what can be done given the technical constraints we have. Any arguments should concentrate on that.

Regarding

OTOH the roads have IMO too much weight in this style overall.

This is about the overall weight of the roads in the map, in particular the choices of dropping other features and de-emphasizing them at lower zoom levels while roads are kept as they are. See in particular #747, #1748, #2654, #2933, #3467.

A lot of comments on suggested changes we have on this issue tracker are anxious of any changes that might negatively affect the visibility or roads while usually no similar concerns are raised on other features like path/tracks, landcover etc. So in a way i also think we have kind of a bias towards OSM-Carto being primarily a road map.

[kocio-pl]

I didn't mean to hijack this PR to discuss general ideas (if I understand your objection right). I thought that adding basic context for my bullet points would help understand it, but if that doesn't work for you, you're free to skip it and concentrate on practical discussion about goals of this code change. I want to make decision easier by not getting too much into details at once.

[kocio-pl]

@matthijsmelissen What do you think about my findings? Any ideas about that?

[matthijsmelissen]

Unfortunately I don't see a clear way forward here, so I'm going to withdraw this pull request.

If anyone else would like to take over from here, feel free to go ahead.