Building doesn't render on top of highway areas any more

[sb12]

Example way: http://www.openstreetmap.org/way/104978884
Other example area: http://www.openstreetmap.org/#map=19/52.52496/13.36941

This happened after the recent style changes a few days ago.
Before buildings and roofs were rendered on top of the highway areas (and highway ways with covered=yes/tunnel=yes) and you could still see the highways because of the building transparency. Now you can't see the buildings anymore when there's a highway area inside.
Is this a wanted behaviour or an error?

[dieterdreist]

2014-07-02 19:19 GMT+02:00 sb12 notifications@github.com:

Is this a wanted behaviour or an error?

it is desired for buildings, as something is either a highway area or a
building (mappers should create a multipolygon to cut out the building),
but it is a bug for roofs.

[matthijsmelissen]

We will be removing the building transparency, and therefore this change was necessary.

In general it is desired behaviour, see #623 and https://lists.openstreetmap.org/pipermail/tagging/2014-June/018043.html.

But I agree the results for building=roof (first example) and platforms in buildings (second example) might be improved, so I think we can leave this issue open.

[sb12]

In general it is desired behaviour, see #623 and https://lists.openstreetmap.org/pipermail/tagging/2014-June/018043.html.

Thanks for the explanation, I somehow didn't find this commit.

as something is either a highway area or a building (mappers should create a multipolygon to cut out the building)

Not necessarily. Sometimes a building can cross over a highway area. Example: http://www.openstreetmap.org/#map=19/49.00904/8.40940 (Picture: http://presse.karlsruhe.de/db/stadtzeitung/gemeinderat_sorgenkind_kronenplatz/13073/sz13_11.jpg)

Same problem for arcades in regions that are mapped very detailed.

Maybe the layer or the covered tag could help with distinguishing between missing multipolygons and overlapping buildings/highways?

[sb12]

I thought again about this and found a simple solution to this issue:

What about having a second half transparent (opacity=0.3 or similar) building layer on top of the highway layer. Example rendering:

Note that this only works after removing transparency and adjusting the colors for the main building layer.

[Theodin]

It looks nice but might make the map more complicated and less readable.

[matkoniecz]

Nice idea, seems to be quite readable. But IMHO it would be probably better with transparency reduced a bit.

[dieterdreist]

2014-07-03 9:43 GMT+02:00 Mateusz Konieczny notifications@github.com:

Nice idea, seems to be quite readable. But IMHO it would be probably
better with transparency reduced a bit.

agree that this works nicely here, but it is still a hack and will not work
for more complicated situations. Honoring the layer tag for buildings and
highway-areas would resolve more universally the issue.

[Morphan]

I agree for the consideration of the "layer"-Tag.
Here is an example for this situation: http://osm.org/go/0GGmPABd5
The area partially reaches below the buildings which are standing on columns:

(The photo shows a different part of the building but with the same architecture.)

EDIT: Original link to image (http://www.loaditup.de/821249-8u5ftpqg37.html) broken, replaced.

[matthijsmelissen]

Thank you for the additional example.

[kocio-pl]

I also gave similar example here: #685 (comment)

[simonpoole]

@dieterdreist a pedestrian area that is partly covered by a building is IMHO a valid situation (just as it would be if it was mapped as a way)

[matthijsmelissen]

This also affects the Eiffel tower: http://www.openstreetmap.org/#map=17/48.85740/2.29346

[Circeus]

Another partly overlapped building. This one is more covered than hidden. I'm pretty sure you can't use a multipolygon here.

[matthijsmelissen]

And this is how it looks in real life.

[matkoniecz]

@Circeus Maybe mapping pedestal as a separate building:part that would be inner part of multipolygon would slightly help. Unfortunately I found no usable data that would allow this.

[Circeus]

FWIW I should mention I don't have local knowledge. I sort of randomly mapped the Plaza a few years ago (IIRC, because I was adding churches from Wikipedia NRHP articles in the area and the Plaza was a poorly tagged mess).

[matkoniecz]

Even with this proposed change display of roof would be still really bad.

[Rovastar]

There are multiple issues here really.

One that keeps coming up is that on pedestrian streets/areas there are often buildings, walls, etc and none of these are rendered, often these pedestrian areas will contain notable/famous buildings/landmarks. (I am not sure people have mentioned they are mostly pedestrian areas this is an issue)

I would argue that the roof one over other highways (you know the ones with cars, etc) is a different issue and more of noticeable in even more micro-mapping scenarios.

Could we do something for pedestrian streets and render these differently?
Thinking about a messy separate section for pedestrian streets in the project that will render before the buildings and all other highways done later and rendered as normal.

[kocio-pl]

Eiffel Tower has been cleverly "hacked" (by not rendering part of the pedestrian area: http://www.openstreetmap.org/relation/4114062), but the problem still exists. Do we need to tweak everything affected or there are some plans to resolve such issues in a more clean and general way?

[matthijsmelissen]

The Eiffel tower solution looks nice, but likely breaks routing across the square, so that's not a solution.

Now the building changes have been merged, we can start thinking about a change to the stylesheet that solves this issue.

[cwmke]

I'm having a similar issue with barriers not appearing in pedestrian/footway areas as shown below. It shows the difference in rendering between here and OSMAnd+ on Android.

[kocio-pl]

This problem has its own ticket where you can discuss it: #528.

[cwmke]

Thanks @kocio-pl. Missed that one in the sea of similar issues :-).

[HolgerJeromin]

Interesting case of a floating entrance:

The solution is a pedestrian way (with round edge) running right to the entrance:

This small way could be retagged as a footway (mapillary image) but still interesting.

[jragusa]

An other example:
https://www.openstreetmap.org/node/4492013017

[Elefant-aus-Wuppertal]

Hi, I just wanted to ask whether I can help in this issue maybe?

[imagico]

This is a hard problem because there are several conflicting goals - as discussed above (specifically in #688 (comment) and #688 (comment) for example).

One possible approach to the problem was discussed in #3872. This was neither rejected nor approved and could be re-visited. But it comes with drawbacks.

[jeisenbe]

Re: #3872 - that option might be more popular if we removed the highway=pedestrian casing or continued to render it below highway area fill.

[stragu]

Another example of area affected by this issue: https://www.openstreetmap.org/way/686546745#map=19/-27.49722/153.01578

The pedestrian area (highway=pedestrian) on the left covers a roof entirely (object selected), the area on the right (highway=footway) covers part of a roof.

Here is a screenshot of the issue:

Noting that the following renderings don't have that issue:

• CyclOSM
• Cycle Map
• Transport Map (although I feel it doesn't render the pedestrian/footway areas anyway)
• Humanitarian

[Sirorezka]

Hi,

Sorry, it's not clear. Why can't you downgrade "area=yes, highway=pedestrian" and "area=yes, highway=footpath" (or same with multipolygon) to level of "amenity=parking"? This will solve the issue.

[Sirorezka]

Also it's not clear why you regard the issue of "pedestrian areas" in bulk with "rendering all highway areas" and "rendering pedestrian ways". I suggest to split them into three tasks (or two tasks: "pedestrian area" and "pedestrian way").

Basically at some point this task became a grave of anything related to "area=yes, highway=*"...

Here is my break down:

1. pedesrian area visualization
   Issue with pedestrian areas visualization #4832
   Canada's CN Tower not on top #4668
   Building above pedestrian area not rendered #4540
   Building doesn't render on top of highway areas any more #688 (comment)
   Potential incorrect rendering of pedestrian area on top of tunnel and subway  #4370

2. general ideas on priority of highway area layer visualization
   Rendering order buildings / roads / highway-area #172
   Move highway areas below all linear road types #3872
   Do not render highway areas in between the road layers #3281
   Render tunnels on top of buildings #623

3. new feature - "highway=*, area=yes" passing a building:
   Highway areas should be rendered according to tunnel/bridge tagging #4544

4. Issue with pedestrian way that is connected to the buidling:
   Building doesn't render on top of highway areas any more #688 (comment)

5. Pedestrial areas hide tunnels (my suggestion will solve this issue as well)
   Render tunnels above highway areas #529

6. Non related issues mentioned here:
   Add rendering to landcover=grass and landcover=trees #2548
   historic=castle z-index/opacity #3190

7. Non support of visualization prioritization for objects with different layer value "layer=":
   Fix #996 by adding intermittent water bodies support #3104

8. Underground rail tracks rendered above the building:
   http://www.openstreetmap.org/way/23691951

9. Danger of introducing opacity in mapping:
   Alternative to pnorman's building style #590 (comment) Alternative to pnorman's building style #590 (comment) and Drop polygon-opacity from landcover #792

10. Danger of rendering underground buildings
    Render underground buildings different #552

[imagico]

Sorry, it's not clear. Why can't you downgrade "area=yes, highway=pedestrian" and "area=yes, highway=footpath" (or same with multipolygon) to level of "amenity=parking"? This will solve the issue.

@matthijsmelissen already answered this in #172 (comment). You can read up a more detailed discussion of this idea in #3872.

Also note by the way that pedestrian areas on top of buildings are probably similarly common in reality as pedestrian areas underneath buildings or building=roof. So your 'solution' would (w.r.t. buildings, other issues are a different matter) just shift the problem.

Also it's not clear why you regard the issue of "pedestrian areas" in bulk with "rendering all highway areas" and "rendering pedestrian ways".

highway=pedestrian polygons are considered together with other road polygons we render (in particular highway=service but also highway=platform/railway=platform) and linear highway=pedestrian because they are - both by us and by mappers - considered to be part of the road system and subject to the road mapping conventions, in particular with connectivity rules and the use of tunnel=*/bridge=*/layer=*.

[Sirorezka]

On your examples:
#172 (comment) - he mentioned problem with "road casing" (rounding last nodes for ways). I think this is much smaller issue compared to not visualising buildings, gardens and etc on top of pedestrian areas. Also I saw that in most related issues mappers ask to visualise tunnels and roads that go under the pedestrian area.
#3872 - is discussion about general rendering prioritizaiton. Not problem with pedestrian layer. Back to my point that you avoid looking at the pedestrian problem separately.

Also note by the way that pedestrian areas on top of buildings are probably similarly common in reality as pedestrian areas underneath buildings or building=roof. So your 'solution' would (w.r.t. buildings, other issues are a different matter) just shift the problem.

I've mentioned this layering problem in my comment. See point about "7. No support of visualization prioritization for objects with different layer value". Completely agree with you on this, as of now you can't see gardens on top of buildings, swimming pools, parkings( !) and etc. This is also quite a huge issue. But if accepting that areas with assigned "layers" are not visualised accordingly then pedestrian on the roofs shouldn't be visible similarly to roof gardens, roof playing grounds, roof swimming pools, roof parkings and etc.

First of all this 'layer tag' visualization question should be a separate topic. The quick fix here might be also quite simple. First visualize everything with "layer=0" (or without 'layer' tag) accordingly to your prioritization schema. Then visualize "layer=1" without prioritization, after "layer=2" without prioritization and etc. If a mapper is using layers then he has enough experience to take into account difficulty of the area that he is plotting. So I can assure that he would assign layers to everything to prevent and fix any possible visualisation issues.

highway=pedestrian polygons are considered together with other road polygons we render (in particular highway=service but also highway=platform/railway=platform) and linear highway=pedestrian because they are - both by us and by mappers - considered to be part of the road system and subject to the road mapping conventions, in particular with connectivity rules and the use of tunnel=/bridge=/layer=*.

Just to breakdown this topics: we are talking about wiki hierarchy and about carto hierarchy. I think they might be different. For example you are excluding some objects that are plotted by mappers (underground buildings and etc), but they are part of wiki hierachy. This is done because you have your own hierarchy of objects. As I said "highway=pedestrian" can be convereted to parking in carto hierarchy.

[imagico]

#3872 - is discussion about general rendering prioritizaiton.

No, it is not, this is the discussion of the idea of moving the rendering of road polygons from within the road layers to before them (which is the same as what you proposed to 'solve' this issue).

As i wrote above:

One possible approach to the problem was discussed in #3872. This was neither rejected nor approved and could be re-visited. But it comes with drawbacks.

So if you want to pursue this idea again you need to look at the discussion we have had there and try to address the concerns raised.

To avoid misunderstanding: 'Road casing' refers to the darker outline we draw around the road fill at higher zoom levels. For consistent results this needs to be drawn below the road fill but correctly ordered according to bridge/tunnel/layer tags to ensure proper display of where there is connectivity in the road system and where there is not. More detailed discussion of this can be found here.