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.