Render underground buildings different

[matthijsmelissen]

We have some buildings in the database that are fully underground, such as parking garages. Due to the Dutch BAG Import, the number of such buildings has drastically increased. They are typically tagged with a negative layer tag: Example.

It would be good to render such buildings differently, for example with no fill and a dashed outline.

[Rovastar]

I would say we should not render any level<0 at all.

[dieterdreist]

2014-05-22 1:31 GMT+02:00 Rovastar [email protected]:

I would say we should not render any level<0 at all.

You are talking about level, which I don't think we have available as key
in the db: http://wiki.openstreetmap.org/wiki/Key:level
If instead you wanted to write "layer", then this is available but doesn't
say anything about on the ground vs. underground:
http://wiki.openstreetmap.org/wiki/Key:layer
There is also the key: "location" with values like "underground".

IMHO we could render also underground stuff but they should be visually
distinct and contained.

[lest69]

Note that the example in the OP is actually using the "level" tag, not "layer" as originally stated, although the BAG Import documentation says "layer" should be used.

[matthijsmelissen]

Good spot, that is a tagging mistake which I will correct. It should have been layer.

[matkoniecz]

Note that negative layer doest not imply that object is underground. For this purpose location=underground should be used (that is not available in the current database).

[Rovastar]

I disagree. A negative layer should be used for tunnels, etc. Therefore the inference is there.

[matkoniecz]

-1 is also frequently used for waterways under bridges.

[gravitystorm]

@Rovastar no, -1 just means below features that are at local ground level. So a road in an underpass could be tagged layer=-1 without that implying being in a tunnel.

[matkoniecz]

Note also that it is typical to use negatives for objects below local ground level but it is necessary only in case of intersecting objects.

For example underground silo in remote area may be not tagged with any layer value (but with location=underground).

[dieterdreist]

Il giorno 29/ago/2014, alle ore 12:09, Andy Allan [email protected] ha scritto:

@Rovastar no, -1 just means below features that are at local ground level. So a road in an underpass could be tagged layer=-1 without that implying being in a tunnel.

no, layers are only indications relative to other features at the same spot. You cannot infer overground or underground from it, but only which feature is over the other where they cross.

Typically tunnels get negative layers and bridges positive ones but this is only a convention to reduce oversights, because features without layer tag are on layer 0

[scat0324]

I came here looking for a solution to the rendering of Oxford's Radcliffe Camera building http://www.openstreetmap.org/#map=19/51.75337/-1.25390 - this is a round building in the middle of a courtyard and an iconic view of the city (http://www.geograph.org.uk/photo/801213). Showing the underground building on top of the grass means the map isn't really showing what someone would see if they visited - what's "on the ground". Could the underground buildings (with negative layer= tags) be rendered underneath the elements of the courtyard (e.g. the grass, which has layer=1 on it)?

[matkoniecz]

with negative layer= tags

Please read previous comments, especially #552 (comment) and #552 (comment) and #552 (comment)

[althio]

I think the suggestion from @scat0324 can be understood as "honor the layer tags".
Not necessarily layer<0 but rather render A above B if A:layer>B:layer.
Related to #688

[scat0324]

Ahh, yes @althio has it. I came here looking for underground buildings, saw the problems described with the level= tag, wondered if layer= could be dealt with instead, and should have searched again in order to discover #688. Apologies for derailing the issue with more general rendering of undergound buildings.

[kocio-pl]

@althio: That's exactly what I'd like to be in #688 - layer is an abstract way of defining what is above/under, so it should be respected by software. Some features - like tunnel - needs to be rendered different and we have to define what is default in layering if a mapper omits such an information (for example B>A), but when she says A is layer 1 and B is layer 0, then we should render it like A>B, because now we know what is covered by what.

[dieterdreist]

2015-02-12 17:30 GMT+01:00 kocio-pl [email protected]:

layer is an abstract way of defining what is above/under, so it should be
respected by software. ..., but when she says A is layer 1 and B is layer
0, then we should render it like A>B, because now we know what is covered
by what.

no, we should not confuse cartography with aerial photography.

[kocio-pl]

Well, if the data sticks to the reality, we have no reason to claim the standard (not specialized) map should not follow it when possible - isn't it?

I mean that there are some exceptions of course, when we really want to see something not visible from the sky (like tunnels), but in general the layering is a valuable hint what to show on the map and what should be hidden. Aggressively overriding this (because the software ignores tagging) can make a mess - I gave the example of center of Warsaw in the other layering ticket:

http://www.openstreetmap.org/#map=18/52.22888/21.00496

Train platform over all the parking areas, buildings and grass, but at the same time always below pedestrian areas - really? For me it's a broken cartography and even straight aerial one would be more relevant.

My point is we have to know what to do by default with overlapping objects (when no layering hints are given), but when we have these tags, we should use them for rendering purposes more than it is now. We went too far trying to set global layering scheme.

[dieterdreist]

2015-02-17 11:33 GMT+01:00 kocio-pl [email protected]:

Well, if the data sticks to the reality, we have no reason to claim the
standard (not specialized) map should not follow it when possible - isn't
it?

can't agree, and you don't even agree yourself (see below).

I mean that there are some exceptions of course

, when we really want to see something not visible from the sky (like
tunnels), but in general the layering is a valuable hint what to show on
the map and what should be hidden.

see? If there are exceptions, there's no rule. ;-)
This is exactly the point: in a map you choose the style you need to show
something in the way you want, not in the way it ressembles most the view
in reality, e.g. you make roads larger than true scale would suggest to put
emphasis on them, and you might want to render something that in reality is
below above in order to make it visible.

[kocio-pl]

see? If there are exceptions, there's no rule. ;-)

Quite the opposite: if there are no rules, there's no exceptions too (exceptions from what?)... =}

1. I intentionally said about general map. The specialized could be anything, even underground cables net only, but the general is a different beast: it should look more or less like in reality (in my opinion) to be recognized properly.
2. See where it leads us? Of course it's just a matter of consistency with what we want to put emphasis on, but I bet it is impossible to predict all the cases when centrally crafted layering doesn't make sense.

[daganzdaanda]

If it's possible, maybe it's worth testing how the map would look when the layer tag is used to determine the rendering order on buildings and highways. We've seen a lot of areas where it doesn't look good right now, and it's not always bad tagging.

For underground buildings, I'd like to take negative "level" tags into account, or, better "location=underground". Since that's not in the database yet, we can't try rendering yet. But I'd propose something with transparency, similar to how "highway=proposed" looks now.

[matthijsmelissen]

when the layer tag is used to determine the rendering order on buildings and highways.

That would imply that any footway or platform in a train station with a roof would not show up. I don't think that's what we want.

[daganzdaanda]

Roofs need transparency, IMHO. Were they not transparent before the switch to Carto-CSS?

Of course, the stuff under a roof wouldn't be as visible as "outside", but the data is still there for routing, and it could actually help to understand a complex situation better if you see that the footway is not outside anymore.

@mboeringa has an example #1130 (comment)

Right now, I can't understand the layout of complex train stations from the map, because we show too much. Maybe transparent roofs would help a little bit, or transparent underground features.

(side track) Or we could decide to leave out everything that is a roof or has a level<>0 or a location=underground. I hope the 3-D and indoor mapping people come up with good solutions to show all that complex information. Then the main map could be for 2-D on the ground floor, and a quick switch to the 3-D-map is all that's needed...(/ side track)

[kocio-pl]

Roofs need transparency, IMHO. Were they not transparent before the switch to Carto-CSS?

They were and I don't know why it was changed, but I think it was a big mistake. Anybody knows the reasoning behind this move?

Right now, I can't understand the layout of complex train stations from the map, because we show too much. Maybe transparent roofs would help a little bit, or transparent underground features.

I also think that we should move any further complexities to the "public transport" map and leave the main map uncluttered. It won't be a cure for everything - for example Berlin Hauptbahnhof (http://www.openstreetmap.org/node/539318419) has so many levels that no 2D map can handle it properly if we want to show how it is organized inside, but we can at least separate the general shape of the building from its inner view. For now we don't even see there's a building at all!

(side track) Or we could decide to leave out everything that is a roof or has a level<>0 or a location=underground. I hope the 3-D and indoor mapping people come up with good solutions to show all that complex information. Then the main map could be for 2-D on the ground floor, and a quick switch to the 3-D-map is all that's needed...(/ side track)

That would be the ultimate solution of this problem!

[mboeringa]

I hope the 3-D and indoor mapping people come up with good solutions to show all that complex information.

They actually have, but it would require some more concise and clearer documentation, including tagging examples of different buildings that implement the standard right, in the Wiki, because a lot of people trying to tag mixed 2D/3D get it wrong.

The OSM Simple 3D tagging scheme, actually defines a role = outline for a closed way or multipolygon feature part of a type = building relation, to perform the role of the total 2D outline of the building, so without any of the complexity of the individual building parts.

The Bode Museum in Berlin, is actually an example that fully, and properly, implements this proposal, including putting the main tags relevant to the entire building on the building outline, instead of on the type = building relation, thus making it most accessible for both 2D and 3D mapping, and adding a building = x tag on this outline too for rendering. It also doesn't make the fault of adding a building = x tag on the individual building parts.

It is valid to add a building:****_part_ = building_type tag, e.g.:

building:part = office
building:part = restaurant

just don't add a building = x tag on a building _part, as it will cause double rendering in most cases: both the _outline, and the _part_ will render in that case, as most renders assume any building = x must be rendered.

Bode Museum type = building super relation:
http://www.openstreetmap.org/relation/2186879

Multipolygon relation with role = outline that is part of the above super relation (notice all tags relevant for the entire building are on this object, ideal for 2D and 3D mapping):
http://www.openstreetmap.org/relation/4211594

Example of a building:part on the Bode Museum, notice correctly no builing = x set on this:
http://www.openstreetmap.org/way/229997283

[gravitystorm]

Roofs need transparency

I've said this before and I'll say it again. No transparency.

Transparency is used to change the colour of another feature. So if you have a red feature (e.g. a path) and you want to change the colour of it (say to an indecipherable brown), then you draw a transparent colour over the top (e.g. a building).

If, however, you want to draw a roof structure, and still see that there are footpaths underneath, you draw the roof structure first, and then you draw the footpaths afterwards. That way, the footpath colour is consistent, and matches the key.

If you want a special colour of footpaths for when they are indoors, or underground, or whatever, then you achieve that by choosing a colour (e.g. yellow) for the footpath, and drawing it that colour based on its tags. You don't achieve it by drawing the footpath red, then trying to change the colour of the footpath by drawing a big translucent polygon over the top of it and hoping for the best.

Almost without exception, whenever someone says here "we need to draw X transparent" what they actually mean either "we need to change the colour of Y" or "we need to change so that X is drawn before Y".

We do not, and we must not, simply draw everything in strict z_order and attempt to fix it with transparency effects. Draw everything in the correct colours, and in the correct order.

[mboeringa]

If, however, you want to draw a roof structure, and still see that there are footpaths underneath, you draw the roof structure first, and then you draw the footpaths afterwards. That way, the footpath colour is consistent, and matches the key.

Or, as I did, you can use a very fine (cross-)hatch to symbolize the roof structure. This doesn't require transparency, nor should it affect colours of features lying below the "transparent" feature. Of course, there is some influence on colour perception, but with a well chosen hatch, this is acceptable. I think the results I showed earlier, in the issue @daganzdaanda linked, are quite convincing, they should be even better on high dpi mobile devices based on the original vector data (the screenshots I pasted are actually from 100% vector PDFs with no transparencies defined in them).

[kocio-pl]

OK, I miss roof transparency, but I can live without it. What really bothers me is that now we have no "strict z_order" rendering: AFAIR at least the roof and the pedestrian areas z_orders are hardcoded and do not follow layers tagging - am I right?

[dieterdreist]

2015-02-26 11:54 GMT+01:00 Andy Allan [email protected]:

If, however, you want to draw a roof structure, and still see that there
are footpaths underneath, you draw the roof structure first, and then you
draw the footpaths afterwards. That way, the footpath colour is consistent,
and matches the key.

yes, it will be visible, but for the price of another inconsistency: a
footpath underneath the roof will appear just the same as one on or above
the roof.

[Adamant36]

None of those seem very intuitive or clear what they are. I don't know what a good alternative would be though.

[kocio-pl]

Light as a minor building with a dashed outline (as opposed to the light minor with the outline when being on the ground) looks and sounds OK for me.

[Tomasz-W]

I would like to see a test rendering with one of more complicated places from #552 (comment) to rate it.

[matkoniecz]

I would try faint, non-transpatent fill (like one four posts earlier) with a faint outline. Dashes generally tend to work for examples and later fail miserable in real use.

Also, it would be a good idea to test also some more complex cases.

[jeisenbe]

I agree that dashes are a problem. We have too many already, and they obscure complex geometries.

…

On Wed, Nov 28, 2018 at 9:47 PM Mateusz Konieczny ***@***.***> wrote: I would try faint, non-transpatent fill (like one four posts earlier) with a faint outline. Dashes generally tend to work for examples and later fail miserable in real use. Also, it would be a good idea to test also some more complex cases. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#552 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshJBy3ed7tG_PQ91b7P7x7NHuep85ks5uzoXWgaJpZM4B9HX2> .

[jragusa]

from locations provided by @Tomasz-W

https://www.openstreetmap.org/way/129989100
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/225384089
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/289030475
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/457313286
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/388758688
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/64978210
before

after
dashed line

continuous line

https://www.openstreetmap.org/way/64978364
before

after
dashed line

continuous line

[kocio-pl]

Thanks, for me this is more readable with dashed line.

I guess Virgilkapelle building should be not visible at all, because pedestrian area does not have a hole there: https://www.openstreetmap.org/relation/152813#map=19/48.20859/16.37281

[Tomasz-W]

I'm not satisfied with the filled ones.

Let's analyze what's the issue:

• we want to show that there is a building, but
• it's not above ground as usual but it's hidden under ground, and
• we want to show type of landcover which building is hidden by
• we want to show building's edges

Test renderings above looks like some type of building, but it's totally not intuitive that it's a underground one. We should look for a way to show underground building shape and landcover above it at the same time, I think hatching is the only way to do it. @jragusa Can you test locations above (or at least one) with:

• 45 degree hatching with dashed outline
• 45 degree hatching without outline
• 45 degree hatching with very delicate outline
  ?

[Adamant36]

You dont think with hatched people will think its showing a multi-story building/inside mapping or something? Plus, with hatching its usually laying on top of the surface. Not under it. Thats how it is with water bodies at least.

[jragusa]

@Tomasz-W an example with 45° hatched pattern is provided in this comment but I don't think it's a good solution since it's already used for building=roof (#2475). I agree with you about rendering the landcover but it's also the case for roof.

The best answer of all of your remarks would be to only render the shape with a (dashed ?) outline. However, as @matkoniecz said, it looks like a path/track.

So, an intermediate solution would be to use opacity parameter to allow the rendering of landcover through the building as I provided in my first renderings

[Tomasz-W]

@jragusa Can you provide some more exaples of it (opacity parameter version) with some locations which I mentioned above?

[jragusa]

with polygon-opacity: 0.33; (that's look better for me)

[Adamant36]

Its a tad to light. Which makes it slightly hard to see. It looks good outside of that though. How would a large building rendered that way look zoomed out?

[Tomasz-W]

@jragusa Please test more prominent version with polygon-opacity: 0.5;

[jragusa]

polygon-opacity: 0.5;

[Tomasz-W]

I think that switching 2 mentioned rendering methods would give better, more intuitive results: stripes for underground buildings and opacity for roofs. As some of underground buildings are often partly visible (e.g. here) striped 50/50 rendering fits better there.

@jragusa What do you think about #688 in the context of underground/ roof buildings? I think that buildings should be moved above highways to make map more intuitive and readable, because it makes a lot of weird rendered places at the moment.

[jragusa]

@Tomasz-W we need to discuss with @kocio-pl as he manages #2475 about building=roof but I agree about #688. That's would improve rendering tests for both roof and underground buildings.

However, I prefer using hatches for roof because IMO the rendering of landcover is more obstructed than with opacity. This better corresponds to what we expect for roof. If we use hatches for underground building, I would use also opacity to avoid that underground buildings stand out too much.

In term of visibility, I consider the following sequence: major building > building > roof > minor building > underground building

[kocio-pl]

I don't try to manage building=roof ticket, I just marked it as something interesting to do if I will be looking for task. Since we have a working team now and you are testing in reality, you may discuss freely. In the end someone will need to accept it by merging, but it's still a melting pot.

[Adamant36]

@jragusa, how come you put roof's before minor buildings? I would consider a garage more important then something with a roof like a rain shelter or gazebo that doesn't have walls. Also, minor buildings before underground ones isn't so easy to classify. Something like an underground bomb shelter could be more important then a garage depending. Not that I'm saying we should prioritize rendering bomb shelters.

[jragusa]

Trying to exhume this old issue.

@Adamant36 I considered this sequence because initially hatching was tested for roof while lighter colour was proposed for minor building, and hatching would stands out much more.

My starting point is the last rendering I made but changing transparency with a dedicated colour based on the discussions in #4077 and #4078. Does this rendering still satisfy everyone or do you have any alternative ?

[jeisenbe]

Looking above, gravitystorm says pretty strongly: "no transparency." #552 (comment)

I believe the best solution is to stop rendering buildings with location=underground, since the geometry of these features is rarely something that a mapper can confirm to be correct or incorrect.

A different rendering for roofs or greenhouses could be considered in addition, but I believe that should be discussed in the relevant issues. It will be hard enough to find a unique rendering for roofs and greenhouses, without also trying to render underground buildings in an intuitive way.

[Adamant36]

Looking above, gravitystorm says pretty strongly: "no transparency." #552 (comment)

You don't think his comment might have applied more then compared to now?

I believe the best solution is to stop rendering buildings with location=underground, since the geometry of these features is rarely something that a mapper can confirm to be correct or incorrect.

That's probably a good call, but it might just lead to people not using the location tag anymore.

Also, functionally what's the difference between something like say the color distortion caused by the intermittent pattern on a body of water rendered above something else compared to the color change due to transparency?

[jragusa]

I believe the best solution is to stop rendering buildings with location=underground, since the geometry of these features is rarely something that a mapper can confirm to be correct or incorrect.

I'm not against. We have already removed the mapping of underground parking.

A different rendering for roofs or greenhouses could be considered in addition, but I believe that should be discussed in the relevant issues. It will be hard enough to find a unique rendering for roofs and greenhouses, without also trying to render underground buildings in an intuitive way.

What about man_made=reservoir_covered (#2620) ? At least in France, they are mapped on cadastre.