I think front and back of a roof is kinda hard to grasp, whereas top and bottom are easy, but do not apply well to all roofs.
direction is mainly use for skillion, so top and bottom do match back and front. any other roof where direction is needed ?
The direction is needed for most types of roofs, with very few exceptions (e.g. dome, onion). Iâve made this illustration of the meaning of roof:direction:
Note that with some roof shapes (such as hipped or gabled), there are two possible directions that yield the same result.
The âback to frontâ definition is based on the direction key. It can also be phrased as âthe direction the roof is facingâ.
So if Iâm reading the previous posts right, the plan is to add a page that documents roof:direction in more detail, and advertise using this tag instead of any alternatives? I would be happy with that.
As for the âdownslope directionâ: That definition would unfortunately be ambiguous with roof shapes such as âhippedâ, as there are multiple contradicting downslope directions. So we will have to use the more complex (but also precise) definitions.
Edit: After writing this, I noticed that Cactusbone had already started a documentation page. Thanks for taking initiative! Iâve expanded and (hopefully) improved the content a bit, I hope you donât mind.
direction value is often used for skillion roofs. In this case the specified angle is interpreted independently from the building footprint. I does not not snap to any edge angle of the footprint, which makes it very versatile for modelling complex shapes. At least I found many examples, which would not work otherwise.
What about the other roof types? Should the direction snap to the âfrontâ edge (orthogonal)? Results could be weird if the value doesnt match exactly.
There is already roof:orientation=along/across with a similar meaning. It is used 100000+ times.
f4map only uses direction for skillion.
we do not snap at all (but we should for cardinal directions because theyâre not that precise)
for some roofs, along/across is not enough to know how to render it (saltbox and sawtooth for example)
but it whould make sense to snap for those cases. (maybe only for cardinals too, allowing for weird roof not aligned on the body of the building)
OSM2World is the opposite here, it snaps all values to a way segment of the building outline.
I know that this isnât ideal either, as not all roofs are aligned to the building walls. So always snapping makes some cases impossible to model. Only snapping with cardinal directions could be an option, though.
It would be good to agree on a defined behaviour here.
The roof:direction key is indeed the standard choice now, and thereâs no longer a reason to use any of the older tags today. Itâs the most commonly used one, too.
Do you mean automatically replacing the tags in the database? Iâm not aware of any plans to do that. It would be possible, of course, and I would be ok with it as long as the guidelines for automated edits are followed.
@Tordanik: as I can see do you work for OSM2World. In TagInfo I read about the âroof:ridge:directionâ is used by this project. In tag mailing list, we think about editing the âroof:ridge:directionâ too, so wanted to ask if OSM2world can deal with a 90° rotated âroof:directionâ tag for double sloped roofs. So we can change this tag too. Thanks ;D
That change wouldnât be a problem for OSM2World. In fact, OSM2World already uses the same code for both roof:ridge:direction and roof:direction anyway, just with a 90° rotation beforehand.