Openstreetmap-carto: 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 [email protected]:

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 [email protected]:

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: https://github.com/gravitystorm/openstreetmap-carto/issues/685#issuecomment-48529496

[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.

[kocio-pl]

So - are there any ideas how to change the stylesheet? I think it's getting serious after such a long time because such places (with complicated buildings/highways layers) are probably important.

[daganzdaanda]

IMHO we could start by rendering anything that is tagged covered=yes with 50% opacity. No need to change rendering order then. It might still look weird, but it should make it more clear what's going on.

Later, other changes may be smarter, like interpreting 3D-tags or the reative layers, or "location".

[kocio-pl]

Could someone make a test renderings of it? I suggest Berlin Hauptbahnhof as a great example of complex multilevel building, but I'm also very interested in Dworzec Centralny in Warsaw (my hometown).

[jojo4u]

Is this building (http://www.openstreetmap.org/way/23691951) being under rather over a railway=platform layer/level=-3 the same problem or a different issue?

[Theodin]

It is over the platform asn the building is on the surface and the platform is a subway platform with 2 moving stairways leading down.

[kocio-pl]

It looks like the hack with render=no stopped working and Eiffel Tower is now broken too.

@gravitystorm Andy, so what about such important places? Do we still accept this class of problems as unavoidable cost of better showing the pedestrian areas (as we do it now) or maybe we should have kind of workaround for such exceptions?

[matkoniecz]

"render=no" never had any effect on whatever something will be rendered.

[kocio-pl]

So maybe that was something else - I just know that building was visible back then, but the problem is what in general should we do with such things?

[malenki]

Every time I see an amenity=fuel with a building=roof and layer=1 with service highways going over them I sigh inwardly.
Now I even bothered to search for this issue to write this comment.
A solution would be nice.

[HolgerJeromin]

@malenki tag the service roads with covered=yes and they will look nicer.

Edit: i just added this "hint" to the English and German fuel wikipage

[jojo4u]

Edit: i just added this "hint" to the English and German fuel wikipage

No, not yet. This is undiscussed since layer=* is technically speaking enough. This is a shortcoming of the renderer. See #1710

[HolgerJeromin]

covered is Status: Approved
And it is not wrong from the data point of view. If it helps current rendering it is good to add it to the fuel documentation!

Please readd it (and access, as it prevent often shortcuts in routing)

[jojo4u]

I opened a topic on the talk page: https://wiki.openstreetmap.org/wiki/Talk:Key:covered#What_to_do_with_building.3Droof.3F

[mboeringa]

This is undiscussed since layer=* is technically _speaking enough_.

I think it is more appropriate to say that it is _theoretically_ speaking enough.

The technical implications of having to properly render buildings or other polygons over or under roads, _or any other line feature_, based on the layer=x tag, is far more complicated, and AFAIK, hasn't been really implemented in any renderer yet, except maybe those fully focusing on 3D, like F4Map...

[sladen]

I don't think this can be batted away on the basis of requiring layer=x, as the Effiel Tower (with layer=4) demonstrates:

• http://www.openstreetmap.org/way/5013364

[kocio-pl]

I find the Eiffel Tower to be a major bug of a new policy (highways always on top of buildings) cartographically wise.

[daganzdaanda]

In case of the Eiffel Tower, the highway=pedestrian with covered=yes http://www.openstreetmap.org/way/308077768 should be rendered differently. Since transparency is evil, we could introduce another solid colour (darker?). Following this with all the other things that could be covered, we would need a lot of new colours!! Seems unlikely to be possible without conflicts with existing colours.

So what about @mboeringa s idea of a hatching / chessboard pattern of 100% solid colour? (He does it with roofs, can't find a link)
In the "empty" areas between the solid colour, one will see the thing that is physically on top of the covered area. This way, one could see the pedestrian area and the Eiffel Tower at the same time.
It may be a bit noisy visually, depending on the size of the pattern.

[kocio-pl]

Interesting idea to test. I would like to see this example link very much.

[daganzdaanda]

Now I found it: https://github.com/gravitystorm/openstreetmap-carto/issues/327#issuecomment-85951265

[kocio-pl]

I guess this is done in ArcGIS. Is it possible to do with osm-carto tools?

[mboeringa]

Yes, this was ArcGIS, but why wouldn't a simple fine cross-hatch be possible in carto? There are already single line (non-cross) hatches in use for danger areas and so...

The feature is as @daganzdaanda pointed out based on the building=roof tag, often employed at railway stations.

[kocio-pl]

I was thinking rather about chessboard, because I haven't seen something like this on osm-carto yet. Hatching is obviously possible.

And I don't get the details how it could be done with Eiffel Tower?

[daganzdaanda]

And I don't get the details how it could be done with Eiffel Tower?

The pedestrian area under the tower is tagged correctly with "covered=yes". Because it's a "highway", we render it on top of the building. So my idea is to render the area with a crosshatch, so that the building will show through. That way, all highways can still be rendered on top of buildings, because we can make the parts that are "covered=yes" fake-transparent.

[dieterdreist]

2016-02-18 19:00 GMT+01:00 mboeringa [email protected]:

Yes, this was ArcGIS, but why wouldn't a simple fine cross-hatch be
possible?

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

[daganzdaanda]

If it works, a crosshatch might also be useful for showing that platforms are "covered" or underground though this will still be more complicated I guess...

[mboeringa]

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

I don't know if "hatch" is the right word to use in the context of mapnik and carto, but in ArcGIS, this is indeed a vector based 'polygon' symbol type, actually a "Line Fill Symbol" to be precise, and two of these stacked on top of each other to create the final cross-hatch polygon fill symbol. So you can't define a cross-hatch directly in ArcGIS, but use a multi-layer symbol instead.

[matkoniecz]

There are following situations

• There is a building above highway area (Eiffel Tower is one example, there is also https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-47841979)
• there is an underground building below highway area (covered also by #552)
• there is a hole in highway area (buildings on a square)

Rendering buildings above highway areas would fix the first issue (at cost of hiding highway area), give unexpected results for the second case and mask data error in a third case. It may also cause buildings to cover linear highway=* objects.

[sladen]

@daganzdaanda, what I don't quite follow here is that 50%/50% cross-hatching stippling exists because the world wasn't able to do proper transparency and blending. And now that we have systems, tools, and file-formats that support proper transparency people are going out of their way to avoid using it.

For solving this we have metadata in the form of the layer= tag, and we have tools in the form of transparency and layering. What I'm unclear about is why everyone appears to be going out of their way to avoid using the two together.

[matkoniecz]

we have tools in the form of transparency and layering. What I'm unclear about is why everyone appears to be going out of their way to avoid using the two together.

Because layering multiple transparent objects gives unclear, unpredictable and ugly results in at least some cases. See for example 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

Transparency has some uses like text halo but it works poorly for polygon fill.

[gorn]

I am not against the change in way layers are defined, but there is no reason to render it the same way is the layer of one object has higher positive value than the other one. That is the core meaning of the layer parameter anyway. I can not imagine any argument against this. What would be the meaning of layer otherwise?

[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 [email protected]:

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 [email protected]:

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 [email protected] 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

1. 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

[Lukas458]

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.