To me, this is nothing more than a flat mansard with one side being cut off, a combination of roof:shape=flat_mansard (something I’ve been using for a while) and roof:shape=side_hipped (which may not necessarily be a natural name but it is what we’ve been using already).
@Zkir is there a way to send you a little tip (e.g. via ko-fi, Buy me a coffee, Github sponsors, etc.)?
I think your work here is outstanding and deserves an acknowledgement!
@rene, thank you very much! Currently it’s not possible, maybe I will organize something like that later :) But if you give the github repositorya star (if not yet) I will be quite happy.
An university in the Netherlands has a project to create some software that makes 3D maps like this. You can click on it and see heights, angles. Although with how it works the data can only be used as reference. It is CC 4.0 (:
I’ve mapped like 30 buildings, 3 of which were pretty complicated. This church would by far be hardest but fun anyways.
I agree on your choices for the two questions, but I feel both should be mentioned (wrt. how to tag) on the roof:shape=saltbox wiki page.
I wish there was a way to specify the “proportion” on each side of the gable/ridge as well.
Excellent!
Could you infer leaf_type from some table of species and/or genus, or do we have to enter the leaf_type even if it is obvious from the genus or species?
(Context: I noticed for a building=tree_house that it is “flying” unless I also draw the trees manually, but even when tagged as genus=picea and species=picea abies it is currently rendered as 4 apple trees
Screenshot: here )
Did I miss it, or how will the height of the other side be specified? A percentage or distance in meters for the location of the gable would definitely be nice, e.g. measured from high to low side.
Regarding fences, walls, or other barriers: Could you support variable height? Typically used when the terrain isn’t flat.
(I have used height:start and height:end for some walls in my area)
Maybe it would make more sense if also the terrain was in 3D, but that might be harder to manage…
We have OSM4D and other proposals in the OSM Wiki, mostly dead. We should mark them as dead and only use it for inspiration to evolve S3DB. There is this page, but also not “alive”.
May be @Tordanik&@Zkir should start a separate thread about improving S3DB. Exactly(!) defining and agreeing about Saltbox may be a good start.
Zkir should start a separate thread about improving Saltbox
@karlos ,my friend, sorry, but I am too tired right now to have long discussions. Also, I don’t even have a definite opinion yet on what might be better for the Saltbox roof. Perhaps I’ll have one when I get around to adding it to the code.
Here’s how a typical “saltbox” building/roof can look like, although this one is a garage (and a rather common garage design in my area). I also show how I tagged it, and how it is rendered in UrbanEye3D:
For roof:direction I’d set it from the ridge/gable towards the lower side.
For roof:height I don’t know which side to pick (right now I think I averaged the two) but if it was possible I guess I could either specify both and the angle(s) which would indirectly tell where the ridge is, or just specify the roof ridge location and the angle(s)…
Notice that roof:angle is already described in the Simple 3D Buildings wiki page as an alternative to providing roof:height. But it does not look like Urban Eye 3D uses that tag yet (the rendering looks like 30 degrees regardless of what I enter, for a gabled roof).
either someone volunteers to create and maintain such table (say, via a page on osm-wiki)
or I can produce such table from OSM data itself. The later case means that all three tags should be specified at least somewhere, so that there is some material for machine learning.
No, it is not feasible right now. OSM 3D is not ready for terrain elevations. Have you checked F4 with activated terrain? It sometimes produces quite strange results.