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?

[gorn]

In case on highway=pedestrian areas with layer=-1 this leads to really strange results. Basically all metro stations will be rendered on top of all buildings. I do not think it is a wise decision. Se an example here #2113

[gorn]

The Eifell tower is still invisible. Althought I appreciate all technical difficulties with layering, you clearly underestimate negative marketing impact of letting it so for so long time. What impression can anyone from "wide public" get if s/he looks at Eifel tower, any undeground station, bigger petrol station? It is very simple ... it is "crappy" for them and it will take another year or so until they will be willing to consider giving it second chance.

So please revert it to the original state and only develop in in some technical branch until all difficult technical questions are discussed/solved. Also as Carto is used in most of the "wide public" applications it hurts the whole OpenStreetMap project. Please, before I will tell that I exagerrate, show the map to someone who does not know anything about OSM, maps, etc. Show them the Eifell tower and other places and see their reaction (the best I got was ... well, why you do not add it to the map yourself when you are saying it is editable :))))) )

[matthijsmelissen]

So please revert it to the original state

Could somebody find out which commit caused this exactly?

[matthijsmelissen]

The Eifell tower is still invisible.

See https://github.com/gravitystorm/openstreetmap-carto/issues/172#issue-19634740 for the rationale behind the current rendering. In the older rendering, we violated requirement 2. In the new rendering, we violate requirement 1. As you will see, this is not an easy to solve problem.

[sladen]

@math1985: Being functional probably wins above worries over tiny gaps in road casing.

And arguably the 'gaps' in the road casing (drawn at actual size) actually improve the rendering by helping to balance the (generally) exaggerated width of the roads.

[kocio-pl]

@math1985:

Violating 1. is an option, but is undesirable as it would require large-scale re-tagging. All the highway-areas with a building in the middle to be tagged should be tagged as multipolygons if we decide to violate this requirement.

So it may be tedious job, but can be fixed, it's just "undesirable", while currently some things (like showing the outline of the Eiffel Tower) are simply impossible, which is worse for me.

There is also another possibility (at least theoretically): smaller areas could be visible over bigger areas. IIRC we use this solution currently with some features like forest and grass.

[matthijsmelissen]

So it may be tedious job, but can be fixed,

We currently do have the option where we violate 1.

There is also another possibility (at least theoretically): smaller areas could be visible over bigger areas.

I don't think that would make a difference here. Rendering any buildings on top of highway areas would imply, assuming highway areas are rendered on top of roads, that those buildings are obscuring the roads.

[kocio-pl]

We currently do have the option where we violate 1.

So it means I'm a bit lost then. =}

I don't think that would make a difference here. Rendering any buildings on top of highway areas would imply, assuming highway areas are rendered on top of roads, that those buildings are obscuring the roads.

I don't understand this case, could you explain it more and give an example?

[matthijsmelissen]

We have three requirements:

1. building should be above highway-area-fill If we violate this, the Eiffel tower square is rendered on top of the Eiffel tower. This is the current situation.
2. roads-casing should be above building If we violate this, we have two options: 2a. Render both roads-casing and roads-fill below building As roads are drawn wider than they are in reality (especially on low- and mid-zoom), the drawn roads often overlap with the buildings around the road. Rendering roads-fill below buildings would mean that buildings obscure the roads. 2b. Render both roads-casing below building, but roads-fill above it. Same as above, except that the buildings now only obscure the casing of the road. This was the pre-2014 situation. See http://i.imgur.com/02qaOv4.png.
3. highway-area-fill should be above roads-casing If we violate, we get ugly effects like in http://i.imgur.com/qTRO1yH.png.

And of course, 1, 2, and 3 are not compatible.

[dieterdreist]

2016-07-14 16:08 GMT+02:00 Matthijs Melissen notifications@github.com:

We have three requirements:

1.

building should be above highway-area-fill If we violate this, the Eiffel tower square is rendered on top of the Eiffel tower. This is the current situation.

we should respect layers, because you can have highway areas above and below buildings and it will not be solvable otherwise.

[gorn]

It is very well possible, that I am missing something very obvious, but I think there is very easy solution. I would call it 0th requirement, because if is the most important (IMHO).

1. layer x+1 > layer x

   Or very briefly, respect layers if defined in data.

This would solve most of the problems. For the rest of the problems we can continue finding sophisticated solution (because the problem still exist if both object have the same layer). In particular it solves - Eifell Tower (and any other towers) and all undeground platforms (whenever mapped).

[matthijsmelissen]

layer x+1 > layer x

That unfortunately doesn't work. It would for example imply not render tunnels under fields, or not rendering railway tracks in stations covered by a roof.

Besides, there are also some technical issues that make this difficult to implement (there is no easy command to tell carto to first order by layer and then by everything else).

[dieterdreist]

2016-07-15 15:49 GMT+02:00 Matthijs Melissen notifications@github.com:

That unfortunately doesn't work. It would for example imply not render tunnels under fields, or not rendering railway tracks in stations covered by a roof.

well, just the same as we render tunnels in a particular way (dashed), we should care for other features that are below of something else. Respecting the layer order does not necessarily mean that it's the same as the rendering order, it means make a style decision to express the fact that one thing is above the other. For rendering convenience it might be required to add particular tags to these covered feature parts (e.g. covered=yes).

[gorn]

That unfortunately doesn't work. It would for example imply not render tunnels under fields, or not rendering railway tracks in stations covered by a roof.

Sorry I do not understand that. It used to be solved before when layer=-1 tunnel=yes was respected, so the same solution applies now.

[matthijsmelissen]

Sorry I do not understand that.

You say that we should render layer 0 above layer -1. Fields are layer 0, tunnels are (or can be) layer -1. So fields are rendered on top of tunnels in your proposal, making the tunnel invisible.

[HolgerJeromin]

Note that we do not have transparent things, but adjusted (dashed) tunnel roads rendered on top/afterwards.

[daganzdaanda]

I fear we are going in circles ;-) The problems are known, possible solutions have been discussed. Now IMHO we need code and a few test renderings to see what's best. I'm really not capable of writing that code, and I'm afraid I don't have the time to start learning now... So - volunteers welcome!

[daganzdaanda]

@dieterdreist wrote...

AFAIK you can't currently do vector based hatches in mapnik, but have to use the PolygonPatternSymbolizer to do it.

OK, so the PolygonPatternSymbolizer is what makes the hatches for prisons, military and allotments? If it can't do a cross-hatch, we could just do a fine linear hatching, maybe 2px wide and in some existing middle grey tone?

It needs to be demo-ed to finetune, a lot of new visual problems could come from a fine hatching.

[dieterdreist]

sent from a phone

Il giorno 18 lug 2016, alle ore 18:29, daganzdaanda notifications@github.com ha scritto:

If it can't do a cross-hatch, we could just do a fine linear hatching, maybe 2px wide and in some existing middle grey tone?

I would prefer a dashed outline of the covered objects

If you go for the filling, this is the docu, but maybe in mapnik 3 you can use svg (couldn't find this out): https://github.com/mapnik/mapnik/wiki/PolygonPatternSymbolizer

[gravitystorm]

If you go for the filling, this is the docu, but maybe in mapnik 3 you can use svg (couldn't find this out): https://github.com/mapnik/mapnik/wiki/PolygonPatternSymbolizer

Yes, you can use SVGs for patterns in Mapnik3 (although there are various technical problems that make this tiresome to implement, trust me!)

[gorn]

@daganzdaanda or anyone else - can you spot the changeset which caused the current situation?

[kocio-pl]

It was done here:

https://github.com/gravitystorm/openstreetmap-carto/pull/623

[eliotb]

Maybe related to #529 #2475 #2509 #2534 #2563 #2630 (my entry point to this)

It seems to me that the overall theme of all these issues is conflict between expectations for highway=something and area=yes when these two tags are combined. Each of the issues may be complaining about a different specific tag (platform, pedestrian,...), or requesting a different solution (transparency vs render order)

A: I think that the common expectation is that "for a given layer smaller areas will cover larger"small areas will render on top of larger areas" irrespective of area type (apart from layer != 0). ([1] paragraph 3).

B: But on the other hand "roads are rendered over landcover" ([1] paragraph 1), and road-like areas are rendered after roads, (to cover up rounded ends of connecting ways?)

My preference is that A should take priority over B for areas. It is really not obvious that if a building/monument/etc is placed in an area (of a particular type only) that a relation must be created, the tags of the area moved to the relation, the area added to relation as outer, the building added to relation as inner. It is also a heap more work for the casual mapper.

[1] https://wiki.openstreetmap.org/wiki/Standard_tile_layer#Rendering_order

[eliotb]

A thought regarding this particular comment:

https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-232675998

3. highway-area-fill should be above roads-casing If we violate, we get ugly effects like in http://i.imgur.com/qTRO1yH.png.

What if the full area is rendered 'lower' with other landuse etc, then a border of the area is rendered after the roads-casing? This would negate the "ugly effects" mentioned above...

[eliotb]

Conceptually similar (IMO) to highway=pedestrian, area=yes are amenity=parking, and aeroway=apron. Both of which do not obscure buildings etc that overlap them, even when all on layer=0

[sladen]

Yes, it is the 'casing' (outlines) that want rendering on top, not the flood fill. This is the classic for tunnel rendering on maps.

[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 https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-201263916 and https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-232675998 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: https://github.com/gravitystorm/openstreetmap-carto/pull/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 https://github.com/gravitystorm/openstreetmap-carto/issues/4832 https://github.com/gravitystorm/openstreetmap-carto/issues/4668 https://github.com/gravitystorm/openstreetmap-carto/issues/4540 https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-871887414 https://github.com/gravitystorm/openstreetmap-carto/issues/4370

2. general ideas on priority of highway area layer visualization https://github.com/gravitystorm/openstreetmap-carto/issues/172 https://github.com/gravitystorm/openstreetmap-carto/pull/3872 https://github.com/gravitystorm/openstreetmap-carto/issues/3281 https://github.com/gravitystorm/openstreetmap-carto/pull/623

3. new feature - "highway=*, area=yes" passing a building: https://github.com/gravitystorm/openstreetmap-carto/issues/4544

4. Issue with pedestrian way that is connected to the buidling: https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-427650977

5. Pedestrial areas hide tunnels (my suggestion will solve this issue as well) https://github.com/gravitystorm/openstreetmap-carto/issues/529

6. Non related issues mentioned here: https://github.com/gravitystorm/openstreetmap-carto/issues/2548 https://github.com/gravitystorm/openstreetmap-carto/issues/3190

7. Non support of visualization prioritization for objects with different layer value "layer=": https://github.com/gravitystorm/openstreetmap-carto/pull/3104

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

9. Danger of introducing opacity in mapping: https://github.com/gravitystorm/openstreetmap-carto/pull/590#issuecomment-44815238 https://github.com/gravitystorm/openstreetmap-carto/pull/590#issuecomment-44787176 and https://github.com/gravitystorm/openstreetmap-carto/pull/792

10. Danger of rendering underground buildings https://github.com/gravitystorm/openstreetmap-carto/issues/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 https://github.com/gravitystorm/openstreetmap-carto/issues/172#issuecomment-1603990058. 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: https://github.com/gravitystorm/openstreetmap-carto/issues/172#issuecomment-1603990058 - 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. https://github.com/gravitystorm/openstreetmap-carto/pull/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]

https://github.com/gravitystorm/openstreetmap-carto/pull/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 https://github.com/gravitystorm/openstreetmap-carto/pull/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.