Talk:ProposedRoofLines

Clarification

I have never heard of an English word - cullis - i.e. I don't know what it exactly means. It is not in the Oxford, Cambridge or Wikepedia.en dictionaries.

I did find it in Websters

1. (Arch.) A gutter in a roof; a channel or groove.

and in

WordNet Dictionary

Noun 1. cullis - a gutter in a roof

This word cullis does not seem to me to be best way to define the roof structure as I don't think that we want to gather data about gutters. I think that what Aschilli wants to define is the roof overhang but I may be wrong. If, however, the roof overhang is what we are talking about then I suggest that "cullis" be replaced by "roof_overhang"

I meant eaves. I was looking for an architectural term. Sorry, I dont speak Oxford English --Aschilli (talk) 13:36, 13 June 2015 (UTC)

So it is the roof overhang i.e. eaves

I am not well versed in your thinking so if the following is not realistic please ignore:

For simple 3D buildings wouldn't the attribute eaves=n (ie. a number > 0.1 meaning 10 cm, 0.5 meaning 50 cm, etc.) be a simpler way of defining the roof overhang.

It would be easy to render (I think)

No, overhanging roofs are not supported at all by this kind of modelling . It's for describing the vertical distance from the ground to where the roof starts, i.e. the height of the transition from wall to roof surfaces. What's the scienticifally correct term then? --Aschilli (talk) 16:04, 13 June 2015 (UTC)

p.s. information on the roof overhang could be indeed added as separate tag, if needed. --Aschilli (talk) 16:04, 13 June 2015 (UTC)

You should get rid of cullis and replace it with eaves or roof_overhang.

I don't know of a scientifically better term.

As for the rendering: You understand that far better than I do so keep up the good work and thank-you.

Suggestions

(I learned about this draft of yours because of [1]. If you do not want to discuss it this early, you can just ignore this post for now.)

It's great to finally see an attempt to define an approach for mapping roof shapes. I've thought about that issue for some time in the context of my soon-to-be-released OSM2World 3D converter, but never got around to setting up a proposal or even draft.

Your ideas are similar to what I had in mind (hopefully that's a good sign ;)), with two exceptions that I will describe below. --Tordanik 16:51, 18 February 2011 (UTC)

• I am looking forward to seeing your converter in action --Aschilli 10:55, 19 February 2011 (UTC)

ridge and cullis heights

You name several possible ways of determining cullis heights in the "Measuring heights" section. However, you do not describe the calculation ridge heights. This is an issue because a building can have multiple ridges with different heights and only the highest ones are related to height/building:levels.

My suggestion is to address this by tagging the height difference between ridge and cullis to each ridge. It would also provide an alternative way of calculating cullis height, by subtracting said difference from the building's height. --Tordanik 16:51, 18 February 2011 (UTC)

explicit vs. implicit roof edges

While it is a matter of preference to a degree, I doubt whether the requirement to explicitly tag all building edges is a good choice. It introduces significant mapping overhead, especially for simple, but frequently occurring building shapes. Raising the way count for a "normal" rectangular house from 1 to 6, for example, is a rather high cost for something that could be considered a niche application category.

Possible solution: Roof edges don't need to be mapped where they simply connect an outline node to the closest ridge node. Implied edges according to this definition would be reasonably easy to calculate and drastically decrease the number of ways required to describe most roof shapes. --Tordanik 16:51, 18 February 2011 (UTC)

Thanks for your valuable comments. One of my intentions was to reduce the necessity of guessing. It is easy to enter something like "building has standard roof type xyz facing to the road", and leave the computation of the exact shape up to the renderer. I agree that this approach would induce some overhead to the majority of buildings. But on the other hand tracing of building footprints from Bing happens very fast and mappers pay little attention to details. Often complete blocks are traced as one way which makes it impossible to add reliable roof information. There should be some resources left for capturing some extra details and to think about structuring. --Aschilli 10:48, 19 February 2011 (UTC)

Naming of tags

Just noticed: all other roof tags got lost of building: prefix, should these tags get rid of it, too? --ACEini 12:57, 10 February 2013 (UTC)

Roof outline

The question remains to which parts of the building roof edges and ridges should be applied. For example, if you have several building parts on different levels, it's probably the top part, but you don't know if the parts overlap and there can be several complex situations. OSM2World handles this by flagging roof:lines=no on building parts where roof lines should not be applied. However, I would also suggest giving the option to define an explicit roof outline (e.g. using a roofOutline role or similar) for which the lines will be applied if defined. In most cases the building outline could also be the roof outline, but it's also possible that some building parts have their own simple roof shape and only some other buildings parts need the roof lines. In practice, you have to define such a line already when the roof overlaps the whole building (OSM2World takes such outlines into account if tagged with building:part=roof). There is also the possibility to apply it only to the building part(s) tagged with roof:shape=many. --Sinuhe20 (talk) 09:41, 11 July 2022 (UTC)

Incoherences

The part "Measuring heights" is wrong (or it is no longer relevant).
The key 'height' is the height of the building (or of the building:part) from ground to the top.
The key 'building:levels' is not the same = it is the number of levels of the building (or building:part) from the ground to the bottom of the roof, see second paragraph or the example on this page Key:building:levels
So what you call 'building:eaves:levels' is in fact 'building:levels'.
But to me more clear, nobody uses (or should use) building:levels because one level is 3 meters and it is impossible to have a good rendering if you have a building wall of 17.3 m. So we used only 2 keys = height and roof:height. The renderings on demo.F4map (for example) are using these rules.
Could you improve this part of your proposal ? Krako73 (talk) 15:01, 6 April 2023 (UTC)