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 notifications@github.com:

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 notifications@github.com 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 https://github.com/gravitystorm/openstreetmap-carto/issues/552#issuecomment-53845730 and https://github.com/gravitystorm/openstreetmap-carto/issues/552#issuecomment-53864614 and https://github.com/gravitystorm/openstreetmap-carto/issues/552#issuecomment-53858762

[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 https://github.com/gravitystorm/openstreetmap-carto/issues/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 notifications@github.com:

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 notifications@github.com:

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

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 notifications@github.com:

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.

[mboeringa]

and do not follow levels tagging - am I right?

I think you meant to say "layer tagging"?

Anyway, maybe this is easier in Mapnik/Carto than in ArcGIS, but realizing a "layer" based Z-order first rendering for all features (multipolygons, closed ways, ways and nodes), while at the same time having "thematic" layers, is next to impossible in many GISs, due to data being handled "thematic" first in most GISs. Putting Z-order first, would in most GISs require an unwieldy duplication of thematic layers (I have only done this for the roads and railways as special cases in my personal ArcGIS renderer)

[daganzdaanda]

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.

That's where extra tags like "covered=yes" come in, as Andy hinted at in the next paragraph.

[saerdnaer]

I created a own issue regarding the level-tag: #1551

[de-vries]

I'd also like to see this issue fixed. When I tag underground parkings I use the following tags:

amenity=parking
building=yes
layer=-1
location=underground
parking=underground

That might give some more options to fix this issue than just the layer tag.

[BalooUriza]

On Thu, Mar 9, 2017 at 6:48 AM, de-vries notifications@github.com wrote:

I'd also like to see this issue fixed. When I tag underground parkings I use the following tags:

amenity=parking building=yes layer=-1 location=underground parking=underground

location=* seems redundant given that you have layer=-1 handling the Z axis and the lat/long handling the X and Y already.

[dieterdreist]

sent from a phone

On 9 Mar 2017, at 14:21, BalooUriza notifications@github.com wrote:

location=* seems redundant given that you have layer=-1 handling the Z axis

layer is not handling the z-axis, only locally with respect to explicitly mapped, crossing objects Objects with negative layer values can well be overground

cheers, Martin

[BalooUriza]

On Thu, Mar 9, 2017 at 7:29 AM, dieterdreist notifications@github.com wrote:

sent from a phone

On 9 Mar 2017, at 14:21, BalooUriza notifications@github.com wrote:

location=* seems redundant given that you have layer=-1 handling the Z axis

layer is not handling the z-axis, only locally with respect to explicitly mapped, crossing objects Objects with negative layer values can well be overground

Really? I've yet to see an instance where this hasn't been true relative to ground level, with layer=0 equal to the ground plane regardless of elevation above sea level.

[dieterdreist]

2017-03-09 14:33 GMT+01:00 BalooUriza notifications@github.com:

Really? I've yet to see an instance where this hasn't been true relative to ground level, with layer=0 equal to the ground plane regardless of elevation above sea level.

have a look at building passages for instance...

[mboeringa]

Really? I've yet to see an instance where this hasn't been true relative to ground level, with layer=0 equal to the ground plane regardless of elevation above sea level.

I think your experience is mostly based on the simple fact that there is a natural tendency for people to not tag anything anything belowground with a 0 or positive layer tag, or anything aboveground with a negative layer tag, simply because it doesn't feel right to do so.

Technically though and based on the Wiki @dieterdreist is right though: layer is just a relative reference of crossing objects.

[AllroadsNL]

It is important to see the examples in this #2579, closed issue.

Then you see there must something be done, especially example 2, not only for building but also highway with underground tag. This is totally under the grass.

[imagico]

Two things that might not have been pointed out in discussion so far:

• Currently we cannot really do much about this because the keys indicating underground features are not in the database at the moment.
• I find it doubtful if it makes sense to render underground buildings independent of their function. The wiki does not specify what exactly an underground building is so such tagging is likely used for more or less any man made underground structure. Rendering something like an underground parking with a distinct function is a whole different matter of course.

[mboeringa]

Then you see there must something be done, especially example 2, not only for building but also highway with underground tag. This is totally under the grass.

In my personal ArcGIS renderer, I do hide these kind of buildings:

As @imagico pointed out, this will need additional keys. Once the database finally is reloaded and hstore enabled, carto could do this as well.

However, whether or not it is desired is a cartographic discussion and will have a wide range of opinions though... it may take time for consensus.

[matkoniecz]

This is totally under the grass.

I would consider underground parking to not be a building. In that case I would simply retag it (underground parkings may deserve special rendering, this is a separate issue).

Though in this case I am not really sure is there consensus how this structure should be tagged.

[AllroadsNL]

It is a building, it has a door in it. It is officially a building in the Netherlands.

[HolgerJeromin]

I am not sure. You can see at most one wall of the structure.

[mboeringa]

It is a building, it has a door in it. It is officially a building in the Netherlands.

I am not sure. You can see at most one wall of the structure.

The building is from the official Dutch BAG buildings administration:

http://www.openstreetmap.org/way/264626824#map=19/52.08511/4.31801 https://www.kadaster.nl/Basisregistratie-gebouwen

This is a legally binding cadastral administration for the Netherlands, so at least from a Dutch "legal" point-of-view, it is considered a building.

Whether that has any relevance to the cartographic discussion here, I leave up to the reader's discretion...

[pnorman]

Let's keep this discussion about OpenStreetMap Carto, not tagging, and definitely not the legal status of a particular building.

---

• layer=-1 cannot be used to determine if a building is underground. It is a relative ordering only. Areas with hills and complex topography will be more likely to have a layer=-1 building not underground.

• Sorting everything by layer is not an option for technical reasons. It is not practical to render something from the landuse layer (e.g. leisure=pitch) on top of something from the building layer with layer=-1 unless everything from the landuse layer is rendered on top of everything from the building layer.

• It's best not to think of parking garages. They have distinct cartographic expectations, and what works for them might not work in the general case.

[mboeringa]

layer=-1 cannot be used to determine if a building is underground. It is a relative ordering only. Areas with hills and complex topography will be more likely to have a layer=-1 building not underground.

Yes and no. From a purely semantical and Wiki point of view, layer is unsuitable.

Reality is though, that almost all buildings tagged with layer < 0, are buildings that people actually want to hide. They specifically set layer=-1 in a vain attempt to see it being hidden by structures drawn over it.

So using layer < 0 in rendering to hide certain buildings can lead to cartographically sound results (at least for 90% of buildings tagged so).

It's best not to think of parking garages. They have distinct cartographic expectations, and what works for them might not work in the general case.

I think parking garages and subway stations currently constitute by far the majority, and probably well over 90%, of all buildings tagged with layer < 0.

So I don't think there is really a "general case". Rather, there are mostly two distinct features for which a cartographic rendering decision could be made.

[AllroadsNL]

Underground building (parking). The forum discussions still coming back, there is the "need" for a answer and solutions to this problem. They watch Carto and want it changed.

And searching for their own solution in how to tag, using only building:part=*. (See images in forum link.)

But their must be a building= , before you can make a building:part=. As I see it; Only tagging building:part=* is wrong tagging.

So, decisions, could be, should be, must be made.

[fgregg]

The prominent park in downtown Chicago has an parking structure underneath all of it. The rendering of the parking structure makes it look very strange:

https://www.openstreetmap.org/#map=18/41.88257/-87.62244

[kocio-pl]

I guess for underground parking (or the one within a building) we could use this icon:

https://github.com/mapbox/maki/blob/master/icons/parking-garage-15.svg

The problem is with underground buildings.

[Tomasz-W]

Maybe "P" character under straight line would be better? An arrow symbol suggest a roof, but underground parkings doesn't have it (not in this shape)