A terrace is an external, raised, open, flat area in either a landscape (such as a park or garden) near a building, or as a roof terrace on a flat roof. - Wikipedia
You would think that this is a very clear and universal definition, but OSM wiki has a different view, using both Tag:building=terrace and Tag:house=terraced for Terrace houses while giving no information in regards of roof terraces. This was quite confusing to me when I happened to discover this firsthand:
This is the terrace staircase I had found yesterday and I was hoping to leave this in OSM database the same way as image shows.
The lack of roof terrace tag was no problem -building:part=yes + height=1 seemed correct at first:
I think the unexpected result you got was because, as you found and linked, OSM expects terraces to be buildings, aka ‘rowhouses’ - houses joined on both sides to another house; it doesn’t (yet?) understand the concept of a terrace also being a raised flat area, for which it would have to use a different term to prevent ambiguity.
From what I can see in your photograph, this raised flat area isn’t actually part of the block of flats/ apartment block, but rather a variation of the ground, and so if instead of a building part, you tag the terrace, and the larger space within the ‘U’ of the apartment block/ block of flats as leisure=park , you might find Carto will then give you what you would like to see. For an approximate comparison, see the image of Town Square Park in Anchorage at leisure=park . That is evidently a public space, whereas this one may be private, but in principle ..?
Although height is implied to be an attribute of a building in the wiki, I’m not sure that it must apply only to a building, and so I hope you will still see the raised area.
I don’t see why Carto wouldn’t render infrastructure, such as air conditioning, on top of a building, although this question may no longer be relevant now. However, solar panels aren’t (yet) shown (to me anyway) unless I log in. A more-experienced user may be able to help with that query.
Incidentally, as I’m sure you will come to add, I noticed the bicycle stand , currently the least of your concerns, and off topic, I recognise - sorry.
building=terrace indeed refers to the UK concept of a single building footprint containing multiple adjacent houses with separate ownership, and not to the idea of a raised area with rooms below and amenities above.
No. A building is an enclosed space with walls and a roof above. A terrace, in the sense shown in your photos, is not a building. It’s just an area of ground that happens to be at a higher elevation than the surrounding ground. I must admit I’m actually not sure how such a terrace would normally be tagged, but it’s definitely not as a building=* or building:part=*.
I guess a rooftop terrace could arguably be considered to be some kind of building:part=*, but again I’m not sure if there is a well-defined tagging value for this.
Here’s what I do: If the terrace is part of a building, it’s a building:part=yes with roof:shape=flat (ditto for regulat buildings with a throughout flat roof) and tag the elements with location=roof and layer=1, if it isn’t attached to any building (just an elevated structure), I simply use barrier=retaining_wall for the flat walls.
The definition of “building” is not straightforward. The OpenStreetMap definition is quite wide and includes not only objects considered as buildings by strict definitions but also building=static_caravan, building=houseboat and may include at least some building=storage_tank.
Even with that in mind, this terrace does, in fact, has walls and a roof and I even suspect that it might be a part of underground parking space which there is.
So, in theory, this should be tagged ether as building:part=roof_terrace
or as building:part=yes + roof:terrace=yes.
Now that I think about it, roof:terrace=yes might be worthy of proposal since it’s not that uncommon:
Well that’s what I did and Carto is still not rendering anything, so the issue still stands (the terrace is connected to the apartments, as you can see on layout).
Carto’s going to do whatever it’s going to do. There are very good reasons why a renderer might want to concentrate less on what is on top of a building and more on what is inside it (POIs etc.). If there isn’t already a good renderer for roof terraces you might need to create one.
That is a rather lackluster way to describe an active opensource project, to say the least. But you are right to say that this is not a right place to continue this discussion.
I’ve come to a conclusion that a terrace itself might have nothing to do with rendering and location=roof should be enough by itself to signal that infrastructure needs to be rendered above the building.
The main problem is that landuse=grass is not rendered - and that is a polygon so it has nothing to do with POI view blocking!
I’ve done some research and Carto team response to a similar problem says that main arguments against rendering pools with location=roof above buildings were pools unavailability to public and rare cases of such objects, so it was too much work and not worth it. However, those are very much not the case for a terrace infrastructure:
These places are very much public and half of the district where I live is like that. This is NOT a single case scenario.
The other point is - not rendering grass on top makes a correct map of terraces more confusing (just look at the images in op post! It is a big difference!). In fact, that kind of rendering approach actually enables people to remove terrace buildings in favor of correct rendering to make map less confusing, but that is exactly what tagging for the renderer is!
THE main OSM style should not enable people to tag for the renderer.
You could perhaps make those points over here, but that’s a github issue created by the most prolific current contributor to the project, opened relatively recently, so I suspect my initial pessimism might actually be misplaced here. However, with a “renderer designer” hat on I think I’d struggle to find a way of representing e.g. “grass on top of a building” to “grass around the building”. The former should obviously still look like a building (because it is one); the latter should not.
Have you considered having a look at the OSM Carto code and think about how you might do that? It’s not that difficult, and it’s even easier to stand up a MapLibre-based style (based on one of the existing schemas that has the data in it you need) with your changes in it.
Hmm, you’re actually right. I can imagine an old shed with roof full of grass that goes completely unnoticeable on a map with roof rendering. A different color, perhaps? Or transparency layer?
Might need to do some head pounding with this one…
I usually leave that to people who are smarter than me :) Well, I might try that, thanks.
Yes, I don’t think rendering “landcover-like” polygons with location=roof after the buildings layer is viable. This is the domain of 3D renderers.
But I think that treating a terrace as a roof is over-complicating things. The terrace is adjusting the ground level rather than being a conventional roof. I think it would be clearer to map buildings / structures below the terrace as location=underground. Adding a layer tag is not useful - layer is only useful to establish the relative order of things like roads etc. It has no effect for polygons.
This does shift the problem, of course. How to handle underground buildings is a long-standing open issue in Carto. But there would be logic in simply not rendering buildings with location=underground, and a PR to implement this might get traction.
At best, I don’t think that always works. Consider everyone’s favourite pig-adorned former power station. There are gardens on parts of the roofs - this tree is at the north end of one. I don’t think it would be a reasonable description to say that the offices immediately below were “underground”.
It looks like the shops which are at “outside street level” are level=-1 inside the building, and the main “inside street level”, which is 1 level higher, is level=0. I think that the gardens are on level 8 or so, but may be out a few either way.
Another challenge with mapping things like this is the parallax…
Well, no - terrace has no limit to which floor it’s on. For example, think japanese schools with open roofs (a roof terrace, right?) or favela roof gardens (this guy):
To explain my emoji - landcover vs landuse has been argued over incessantly over the years. It’s absolutely the case that a number of OSM “top level tags” are a bit misleading - there isn’t a clear delineation between natural and non-natural tags, for example.
An example of previous discussions is this one, but there have been many, many others.
I’m not convinced that introducing “landcover vs landuse” into this topic is at all helpful.
emoji - #/media/File:Pink_Floyd-Animals-Frontal.jpg){kind=link}