It seams that the biggest problem with tag 3dr:direction=begin|end is the name. Unfortunately, I do not know English very well. How in yours opinion this tag should be named?
Is this better:
roof:directon=begin
roof:directon=end
Or
roof:ridge:directon=begin
roof:ridge:directon=end
Or do you have any other idea for name/value?
I can only speak for myself as a mapper: Yes, I don’t like the tag name, even worse is the roof table using numeric values (though there are names for most of them now). But it definitly is not the biggest problem with that tag in my eyes.
I mainly don’t like “your” tag because it is not intuitive/easy to use. Currently I can add any property via your great preset. I click on a house and add the tags. But when it comes to the ridge direction I have to click a node, add a tag, click on a second node, add another tag. I am tagging/want to tag the building/house and not two of its nodes.
Now you might say: This is just a problem of the editor. And you might be right with that. But I think already relations showed us how cumbersome it is to use them. We have them for ages and most editors don’t support them well. Even in JOSM its usage is not so natural and easy as one might hope. I prefer a solution that works with mostly any editor out there, a solution that is easy and intuitive.
However, I also have to clearly note: I see (literally, on the map :)) the disadvantages of OSM2Worlds solution, too! It does not work well in many cases where the building is not rectangular.
But I think we shouldn’t make this a “kendzi’s way” vs. “tordanik’s way” but search for a better way to achive our goal. What do you think?
It´s amazing to see this kind of “competition” but we havo not enoug ressources in 3D. I would say- let´s meet and discuss how to do ONE way. Maybe in summer?
in “Simple 3D buildings” there is a tag roof:orientation = along / across. Can you explain what the 3dr:direction tag does and how it is used? I couldn’t find anything on the wiki, so this discussion is hard to follow. What is the problem / difference in approach you are trying to resolve?
The roof:orientation-Tag is good for simple, rectangular, non-quadratic buildings. But what if you have a “L” or “T”-shaped building, what’s along/across supposed to mean? Where do you expect the ridge to be, especially which direction?
And this is what this discussion is about. Kendzi has two nodes for that. A ‘begin’ and an ‘end’ node that denote the direction of the ridge. OSM2World has a heuristic for that (‘magical snapping’ how kendzi called it) to find a ridge direction that’s possible/probable. So the difference is: Kendzi has a clean way to clearly define the direction of the ridge (however, not the possition afaik), but imo it has disadvantages (see my previous arguments). Tordanik on the other hand uses across/along combined with a heuristic that does not always produce good results on non-rectangular buildings.
Also have a look at Mareks explanation in the wiki here.
Hope that helped 
Thanks for your explanation! As Oliver I didn’t follow the discussion in detail.
Well but maybe this single tag is just an single problem, within the next step of 3D with OpenStreetMap? So questions on how we form a general schema for more complex buildings? This sounds at least for me like a successor of the Simple 3D buildings schema and was mainly the same intention, why I started the “one year Simple 3D buildings” thread. So discussing on where we are now, what (doesn’t) work and how to proceed?
As it seems to be a bit more than just this single tag, what about starting collecting problematic buildings, that aren’t currently covered with S3DB Schema?
Talk:Simple_3D_Buildings#Limitations
IMHO this would make the discussions more plastic and we can later on easily test, if a new schema can cover this examples
@marek At least for me I lack of time. Would be pretty good to meet, if we have some kind of a raw draft (or at least ideas what to improve).
I made description here.
This tag is not about roof table to be clear.
I can only speak for myself as a mapper: Yes I like idea of exactly define direction.
If not selecting two points how do you propose to achieve that?
And finally if we want select direction by two points how this tags should be named?
Moin
just one question: in a line on OSM, there is already the direction coded, or? Can´t that information be used like in other tags (street direction e.g.)?
Amiga4000
Yes, that is another approach, that is already in the wild, like oneway=yes tag shows. Unfortunatly, it becomes more complex with closed ways like builidings. An another idea would be to allow building=wall elements to describte different heightlevels and so on for the building?
P.S. Please let’s use our existing tagging namespaces, or opening new general ones (e.g. fascade or wall), but nothing like “3dr” as it doesn’t say anything specific at least to me 
While I agree with many opinions expressed in this thread, I also think that the name itself is indeed a problem of 3dr:direction, as was suggested in the first post, and would be more open to implement it as one of the possible tagging styles if it were named differently.
Yes, I believe this suggestion is clearly better.
What we also need is a definition of directions like the one you have already uploaded to the wiki. These definitions should of course be identical for all styles of mapping directions.
Finally, there is another open question: If the 3dr:direction/roof:direction is represented as a relation with two member nodes, what should the type of that relation be? It is currently called “3dr”, too. And is there maybe a chance to merge it with the building relation, at least in some cases, to avoid having multiple relations just for a single building?
Am I wrong, or doesn’t taggin like the Aschilli Roof Line Proposal get all possibiltys of Roofs?
http://wiki.openstreetmap.org/wiki/User:Aschilli/ProposedRoofLines
If you’ve got all roof ridges and edges, the direction is clear?
btw, i think its more intuitive to draw lines for ridges from the birdview picture, than tagging something like ‘2.0.aa.b’
It doesn’t work for round roof shapes, such as domes, arcs, onions and so on. It also doesn’t work for roofs with vertical faces such as sawtooth roofs.
A major issue is also the lack of a definition for the case where not all outline nodes are at the same height (this affects a lot of roof shapes, even very basic ones like monopitched and gabled roofs). No such examples are presented on Aschillis own page, and I cannot think of a clear answer on how to deal with them.
I do not think that all aspects are intuitive. For example, you have to correct perspective effects instead of just drawing directly on the ridge where it appears in the imagery, which may not be obvious to all mappers.
It also takes some skills with JOSM to construct ridge lines that are parallel to and centred between the roof outlines. Have you ever tried building a mansard roof with Aschilli’s? It really takes some skill with JOSM and with height calculations, and I have no idea how to do it in Potlatch at all.
For most cases, I believe that applying properly named tags, possibly using nice preset with a 3D preview, would be a lot more intuitive than the geometric operations required with Aschillis’.
Hi things-change, please read: http://www.ifp.uni-stuttgart.de/publications/phowo99/gruen99.pdf also https://www.unibw.de/inf4/professuren/geoinformatik/Seminar_GIS/10_steidler.pdf
or try to find out online more about “cyber city modeler”.
I developed the 2nd specification with optimized geometrical construction trics for this tool.
The approach of Aschilli takes much of this idea.
In general is this idea good but - as Tordanik said - it is very difficult to construct good roof geometry without good CAD tools.
My experience with 3D is: small inaccuracies in the top view causes very significant optical defects of 3D models.
Hi,
The proposal was meant as a kind of amendment to the simple tagging schema. Not to switch completely to a new approach on how to define building and roof shapes. In fact, both approaches could be very well combined if buildings are split into multiple parts. As Tordanik pointed out, round shapes are not supported. Vertical faces could be created if you move nodes or ways with different heights on top of each other, but the OSM editors are actually not made for this. Creating a gabled roof shouldn’t be that difficult, however.
For the majority of building structures it will be possible to define one or multiple parts with typical roof shapes such as gabled or pyramidal. Using Kendzi’s pluign allows us to preview the results very nicely. But some structures do not fit in any category. In these cases it will be necessary to explicitly define the shape instead of using a rule based reconstruction.
So far I only used roof:orientation. I would try to split up T or L shaped buildings.
