Talk:Simple 3D Buildings

Complex Building

Are there thoughts also to allow compex buildings? Might imported from an OSM driven or external Database and created by Blender, GoogleScatchup, 3DsMax, Maya, Autocat or other commertical or OpenSource programs? Is it possible to determinate the scaling of the 3D Model by it's footprint drawn with Josm in OSM? Do we need an quality guideline for adding 3D objects? --F6F 08:35, 22 March 2012 (UTC)

Complex Buildings might be outsourced as 3D model in OpenBuildingModels or to Open3DMap. Scaling and transformations is currently still an issue --!i! 10:24, 22 March 2012 (UTC)

is there an idea how they can be linked in OSM?--F6F 15:40, 23 March 2012 (UTC)

I'm currently only at the very beginning of the journey ;) Currently they will be refered from the external 3d model database (to cover esp. general models) --!i! 18:46, 23 March 2012 (UTC)

Scaling idea

for the scaling ... it might be possible to make an horizontal cut through the 3DModel and export this Building footprint to Josm where it then can be scaled rotated and placed correctly... though an link, the orientation and maybe an scaling value calculated and placed by josm (in the foodprints metadata) the process how the 3D object is to placed is defined --F6F 15:40, 23 March 2012 (UTC)--F6F 15:03, 23 March 2012 (UTC)

Interesting idea. Will think about an JOSM plugin if I will have the platform running :) --!i! 18:46, 23 March 2012 (UTC)

Roof

Roof shapes

Besides roof:orientation=along/across there should be also an additional option for tagging the direction for unsemetric roofs like sawtooth or skillion. Because for there roofs there are 4 ways to be place on the building. --F6F 08:25, 22 March 2012 (UTC)

As we decided at the workshop, to keep this first tagging preset very simple, I would recommend to drop this roof types instead. Later on we can expand the catalogue or use manual roof modelling techniques as suggested by Aschili --!i! 10:21, 22 March 2012 (UTC)

Yes, it is true that along/across alone is not enough for some of the shapes currently listed. As we don't yet have a consensus which of the ideas for more expressive orientation tagging we want to use, I suggest to "formally" introduce sawtooth and skillion only as part of a future batch of roof shape values and remove them from this page until then. (However, I definitely think that they should ultimately end up in the list of supported values. And note that Aschilli's lines don't work well for these roof types either.) --Tordanik 22:50, 22 March 2012 (UTC)

• Douh* sorry you are right, can't be modelled manually, that was why we decided it to be added to the list *my mistake* --!i! 05:48, 23 March 2012 (UTC)

Im missing http://en.wikipedia.org/wiki/Pitched_roof roofs (http://de.wikipedia.org/wiki/Pultdach)

Regards --F6F 09:23, 14 July 2012 (BST)

These were called roof:shape=skillion in an earlier version of the page. [1] You can still use that value, but they are currently not listed because roof:orientation=along/across isn't sufficient to define their orientation. --Tordanik 12:42, 14 July 2012 (BST)

Roof only

Question: what is the appropriate tagging for a roof covering an area with no walls? This is quite frequent in train stations, bicycle racks and gas stations. building = yes doesn't feel right. OliverLondon 22:04, 16 April 2012 (BST)

Some use building=roof, others man_made=canopy if the structure is not a building in their opinion. Alv 08:23, 17 April 2012 (BST)

In French community we're using wall=no for such cases, cmif4 24 Sept 2013

roof:angle

Could, please, someone write, what is roof:angle? Is it angle between plane of pitch and horizontal axis or angle between plane of pitch and vertical axis? Dinamik (talk) 13:20, 25 September 2013 (UTC)

I'd currently refrain from using roof:angle, as support is sparse, F4 does not seem to support it, the tag is simply ignored. Greetings --Cmuelle8 (talk) 20:27, 26 September 2013 (UTC)

Yes we don't handle roof:angle in F4Map because it's hard to imagine the final result with a shape and an angle. Cmif4 27 Sept 2013

roof:direction / roof:slope:direction

If I add roof:slope:direction=N/E/W/S to the skillions of 3228164 3228164, kendzi3d plugin seems to slighty get the roof direction vector wrong (3rd pic below). If roof:slope:direction=* is removed from all of the four skillions (2nd pic), roof edges become seamless / render correct.

• 

  Ratskeller Ratskeller - F4 WebGL (view)
  without roof:slope:direction=*

• 

  Ratskeller Ratskeller - Kendzi
  without roof:slope:direction=*

• 

  Ratskeller Ratskeller - Kendzi
  with roof:slope:direction=*

• 

  Ratskeller Ratskeller - F4 WebGL (view)
  with roof:slope:direction=*

In an earlier version, I did not use roof:slope:direction at all and, as stated above, the building rendered fine in kendzi3d without. However, in F4's map the direction vectors are not assembled right (1st pic). Their changelog says they make use of roof:slope:direction, this is why I'm trying this solution.

I check this building. Kendzi3d use roof:direction or roof:slope:direction tag in two modes. When you put number value, it render roof using given angle, but when you put values like N, S, E, W etc. it try to snap angle to best matching wall. It seams that inner wall is better matching direction value, so it can cause errors you described. Example of it you can find on roof direction section --Kendzi (talk) 17:55, 27 September 2013 (UTC)

Thanks. Although angle snapping is not perfect using letters, results seem to be consistent between your plugin and F4 - I added pic above. Since I do not know if number value is supported by F4, I'm satisfied with this result and leave it untouched until tag is more developed and used productively elsewhere. Greetings --Cmuelle8 (talk) 18:43, 27 September 2013 (UTC)

What I'd rather use is roof:direction=begin (on the middle nodes of ridge) and roof:direction=end (on the middle nodes of respective outline counterpart), but this only seems to work for right now, and not with building:part=*s entered as multipolygons. Being more specific, I wonder why adding these points as role roof:direction:begin/end or direction:begin/end is not handled in the same way as it's closed-way-counterpart (with begin/end nodes). This tag is still in flux, but it would be nice to have consistency between and representations of the same thing.

roof:direction:begin/end as multipolygon roles, are not supported in kendzi3d yet, I will add it soon.--Kendzi (talk) 09:44, 27 September 2013 (UTC)

roof:direction:begin/ roof:direction:end fixed in kendzi3d v232 --Kendzi (talk) 20:38, 27 September 2013 (UTC)

Thanks. What about (yet another) alternative to code the slope of a skillion/monopitch roof:

• Enter the height of three (fourth is not needed but could be given) corner points of the roof.

This would be easy to understand and easy to translate from measurements taken in reality. Rationale: It's hard to directly determine roof slope, but relatively easy to measure the height of three corner points of the roof, either using triangulation or a laser measurement device.

As a side effect it becomes very easy for mappers to align the roof with other edges or exactly the edge they think is most desirable to connect the roof or roof segment to. Greetings --Cmuelle8 (talk) 20:50, 29 September 2013 (UTC)

If roof:height is always understood as the difference between lowest and the highest point of a skillion, then another way to make use of this variant would be to mark/add tag

• on highest point (or add as role) with something like roof:peak or tip or top=yes
• on lowest like roof:nadir or bottom=yes and

• tag a height on the third node, being a corner of the skillion rectangle, lying within the range between lowest and highest, and
• additionally tag it (or add as role) with roof:third or middle=yes.
• if /no/ third point is marked, fallback by interpreting the highest point as roof:direction=begin and the lowest point as roof:direction=end

--Cmuelle8 (talk) 21:10, 29 September 2013 (UTC)

I don't think multipolygons should get special treatment with additional roles. Any such extensions are not future-proof for the planned area datatype. --Tordanik 10:07, 30 September 2013 (UTC)

Arguably, handling these roles of a multipolygon is not mandatory to use them. They should just be interpreted by most data consumers as usual, i.e. discarding everything that is not an outer or inner. Atm, empty roles are considered too, because a lot of people do not care to set correct roles - so this adds to discarding every non-empty role member that is not an inner or outer.

The extra members are optionally evaluated by 3D-stuff. Also be aware that they are really needed, just looking at the tags of the nodes of the ways making up the MP will not suffice in each case:

• Imagine 2 MPs that make up adjacent roofs and share at least 1 node thru different ways, indirectly, i.e. the node takes part in two ways that are not both in the same MP.
• This node could be the highest point of the roof of the first MP and the lowest point of the roof in the second MP.

The only way I can think of to get rid of the need of roles in this case is placing two nodes on top of each other, i.e. overlapping nodes, that have exact same location, but two different id. Overlapping ways have been suggested as a solution to some problems in 3d modeling with 2d editors before - for experienced users this might be ok, but ideally the editor should show what you're doing:

• You do not really see overlapping ways without touching them and this would be the same problem with overlapping nodes.
• However it would circumvent the need for point roles in multipolys that are roof building parts, since it would then suffice to extract the info roof:top/bottom/middle=yes by looking at the points of the way members of a MP resembling monopitch roof.

For two points at the same location and in the same height, but with different roles/tags wrt the two roof MP/areas they take part in, it would even in 3d-space be hard to visualize, for an editor, that there are two points - so ultimately I think a role based coding of this information is needed, at least for the time being, else it's very hard to see what's going on, even in advanced editors.

--Cmuelle8 (talk) 17:04, 30 September 2013 (UTC)

I'm not sure, that interpretation of nodes with roles roof:direction:begin and roof:direction:end is working in v232. osm-file,image.

Dinamik (talk) 09:42, 3 October 2013 (UTC)

in yours example is not working middle example, when you have multipolygon and two nodes of way tagged as roof:direction=begin|end. First and last is ok for me. I will try fix middle one. I think that we should put examples xml on different wiki and only put links to them here --Kendzi (talk) 21:03, 3 October 2013 (UTC)

Why do side buildings look different, although begin and end points are the same? I think, that we should not interpret roof:direction begin/end nodes with multipolygons, because it can lead to mistakes (because points can be parts of several multipolygons, we can't understand, to which multipolygon points are related). Dinamik (talk) 22:14, 3 October 2013 (UTC)

Note: Reordering the ways in the skillion part relations gave the perfect result for kendzi3d, but the way ordering is not stable for other 3d renderers: The correct interpretation of the ordering (that is used to determine direction) is currently intrinsic knowledge to kendzi3d's plugin. At least F4 deducts direction vector differently, unfortunately. --Cmuelle8 (talk) 20:22, 26 September 2013 (UTC)

See also: Roof_table#Polygon_direction and #roof_direction, above.

Current sum-up:

• roof:direction=* / roof:slope:direction=* on or building parts currently seems to be the most portable way to code roof directions.
• An alternative being roof:direction=begin/end on a of . This enables coding non-snapping, precise angle without entering numbers. It seems this approach is currently exclusively interpreted by kendzis plugin, please change this if I'm mistaken.

--Cmuelle8 (talk) 20:01, 27 September 2013 (UTC)

Slope direction for roof:shape=skillion

I still do not understand what value I have to give to the "roof:direction =" for "roof:shape=skillion".
In which direction the vector will be to determine inclination to the top?
On the Wiki we have: "direction from back side to front of building", but the lack of information, "front side" has to be higher or lower "
On the Talk page "Talk: Simple 3D Buildings # Limitations", we have shown the direction of the slope from a lower to a higher level and information "from front to back."

Kendzi plugging visualizes inclination and direction other than F4Map for the same value "roof:direction=" --Władysław Komorek (talk) 08:59, 7 November 2013 (UTC)

Based on previous discussions on this talk page, I think that roof:direction should define where the "main" face of the building is directed as I illustrated here. So in the case of skillion, this would be the downwards direction. --Tordanik 09:09, 7 November 2013 (UTC)

Kendzi use a magic "snap to edge" to get direction along the best edge, in F4map we take the "roof:slope:direction=*" as it. It represent the angle in degree between slope direction and north clockwise (0 means low part on north and high part on south, 90 means low part on east and high par on west...). Cmif4 (talk) 09:13, 7 November 2013 (UTC)

Magic it is working only when you use roof direction direction=* saved as cardinal like "S", "NE" etc. When you use number it should be interpreted directly with out sniping to edge. --Kendzi (talk) 10:42, 10 November 2013 (UTC)

Why are using a "roof:slope:direction=*" not recommended "roof:direction ="? --Władysław Komorek (talk) 13:16, 7 November 2013 (UTC)

This is example where Kendzi plugging visualizes inclination and direction other than F4Map for the same value:
Building no 13, roof:direction =135 - http://www.openstreetmap.org/#map=19/51.47287/21.44521&layers=N --Władysław Komorek (talk) 12:55, 7 November 2013 (UTC)

The roof in the shape of an arc

I have a problem with the visualization of the roof in the shape of an arc,
See the roof of the Colonnade at the Vatican.
http://www.openstreetmap.org/#map=18/41.90223/12.45562&layers=N

It should be something similar to the roof:shape=9.0, but "gabled" not "hipped". --Władysław Komorek (talk) 13:11, 7 November 2013 (UTC)

I'm currently working on this kind of roof for F4 Map renderer, i hope it will be online next week Cmif4 (talk) 13:32, 14 November 2013 (UTC)

Saltbox Roof Image not a Saltbox

I was reviewing real-world images of roof shapes, and found that the actual shape of a saltbox roof is like this: https://www.google.com/search?q=saltbox+roof&num=100&source=lnms&tbm=isch&sa=X&ved=0ahUKEwieqfDBivraAhUxwFkKHR8xBqcQ_AUICigB&biw=1366&bih=653. Compare to a flat mansard roof, which is what I'd call what the image shows as a saltbox. Which is correct? I spot-checked some saltbox-tagged roofs in OSM, and some are like the flat mansard, others are like the short/long gabled roof. Pkoby (talk) 02:25, 10 May 2018 (UTC)

Stairs

Do we have a scheme that allows to show the stairs in front of the building such as churches, and side stairs that allow users to go to the side of the building at the "layer = -1" I think that this scheme could be used for entry to the underground garage of the building. --Władysław Komorek (talk) 10:41, 16 November 2013 (UTC)

Trees

--Kendzi 11:05, 25 March 2012 (BST)

Buildings on a slope

How to map buildings on a slope? A building on a slope sort of has two heights. The building seen from higher up the hill might seem smaller than from the other side. I guess one could always tag the biggest height and let the renderer sort things out based on the elevation data (so that no part of the building will float in the air). However, if the same buildings are renderer without elevation, they might appear wrong in relation to other buildings:

Another problem are buildings that are directly adjacent to one another or parts of a building that are separately mapped (building:part). Without the correct slope, the houses may be the right height from the ground, but will not fit together at their respective roofs. For building parts, one could probably always tag the height from the lowest part of the whole building, so it will fit together and let the renderer take care of the rest based on elevation data. Even if this works ok, separate buildings might still pose a problem.

A similiar problem can be seen with terrace houses of the same height on a slope. With no or inaccurate elevation data, the characteristic height difference may not be visible.

I would like to begin improving my area, but I am unsure how. Are there any solutions or guidelines for this yet? --Driver2 12:47, 28 March 2012 (BST)

We actually did talk about this topic at the 3D workshop, and the intended convention was to use the "biggest heights", i.e. measure heights of buildings and building parts from the lowest ground elevation within the area covered by the building (the whole building, not just that building part). That's what "lowest possible position with ground contact" in the definition of height is supposed to mean. I know that it isn't well written, but I have no good idea how to describe it better. Can we maybe add some labels to one of your drawings and use it as an illustration to make this clear?

One motivation for this is that a 3D renderer will usually take the easy route and draw, in the case of your first example, a five-story building with some of it sticking into the ground.

And yes, It's true that there will be misleading visualizations if the renderer uses flat terrain. However, this is ultimately inevitable - buildings on a slope can simply not be represented correctly if ground elevation is not visualized. --Tordanik 15:44, 28 March 2012 (BST)

The problem with assigning elevation to each building:part separately is that if terrain model change eg. If more detailed elevation model will be available all building parts will be wrong. We agree on meeting (more or less) that building outline with all it parts should be added to relation type=building. So can we assume the same ground level ("biggest heights") to all building parts describing one building? In this approach terrain change don't destroy building parts. --Kendzi 21:34, 28 March 2012 (BST)

building:material tag vs. facade:material tag

It was defined building:material=* Outer material for the building façade. <TODO> But also facade:material is available. In a more logical way, I would suggest to use facade:material for the outer, visible material of a building/facade and let building:material be used for the inner core of a building. E.g. a house made completely out of wwood has tags: building:material=wood (and no facade:material tag, if there i sno other material on facade). A typical modern build would have building:material=concrete and facade:material=plaster. If we use building:material for the facade material, which tag should be used for the inner core material a building is built with? --Aceini 09:53, 09 October 2012

+ I agree --Kendzi 18:03, 10 October 2012 (BST)

I don't, see my forum post for the reasons. --Tordanik 14:16, 11 October 2012 (BST)

3D examples

- I think that example images from different renders should be on different sup-page. --Kendzi 08:27, 3 November 2012 (UTC)

- To examples should be always added xml with data, to easily make similar images on different rendering engines --Kendzi 08:27, 3 November 2012 (UTC)

I would be interested in xml data for examples like that, too. And a subpage with examples would be interesting, assuming that we can get enough examples from the different programs. --Tordanik 01:09, 9 November 2012 (UTC)

I'd appreciate simple examlpes a lot, like L-shaped buildings with gabled roofs, once running around the corner, once just extended further down. Examples on how to use building parts with or without relations in order to tag T-shaped houses or houses having a tower on top. Any suggestion for places? Maybe even worth a Wikibook... --RalfG (talk) 14:46, 18 March 2014 (UTC)

Experiences from one year

Hi, I wrote up some of my experiences in tagging 3D buildings with S3dB. Would be great to read about your problems and ideas! http://forum.openstreetmap.org/viewtopic.php?pid=303764 --!i! 17:17, 13 January 2013 (UTC)

Limitations

You noted difficult/impossible to map buildings (or details) with this schema? Please give us examples on what doesn't work well?

roofs

• 

  complex roofs with multiple directions

• 

  Outstanding roofs

• 

  splitted roofs

• 

  tall roofs (maybe with own level)

roof direction

Very nice diagram. But I think the roof direction for the monopitched roof is counter-intuitive and hard to memorize (was the slope towards the left or right of the direction again...?). --Tordanik 20:21, 8 February 2013 (UTC)

There is only need for remembering that direction mean from left to right side of building. Than front is there it should be. The idea is to use only one tag do describe all square-like roofs. For special cases we can always use slope vector witch will be orthogonal to direction. But only as add-on. --Kendzi (talk) 21:38, 9 February 2013 (UTC)

I agree that having only one direction tag for all roof shapes would be good. And thank you for your illustration of the front/back/left/right separation - it makes it clearer to me where exactly I disagree with your suggested definition: I think that it would be better if a "roof direction" points towards the front (for all roofs), rather than towards the right.

Several reasons for this:

• It is consistent with the definition of direction elsewhere, where it also defines the direction where the object is "facing", e.g. the printed side of a billboard.
• It works well for all common roofs: even though not all have a typical ridge, all common roof shapes have "faces".
• It matches natural language - at least in German, where a "Süddach" ("south roof") would be a roof facing south.

--Tordanik 11:47, 10 February 2013 (UTC)

Agree, can you mark direction for rest of roofs? [[2]] --Kendzi (talk) 19:34, 11 February 2013 (UTC)

I've added arrows to some of Marek's roof shape drawings, see above. I've left out roofs which I consider just a special case of another one. For example, I think that shape 1.1 is just monopitched/1.0 with a different direction - do you think so, too? There is also a shape I'm not sure about yet, which is shape 4.3. --Tordanik 19:36, 12 February 2013 (UTC)

• For shape 1.1 I agree it is monopitched with direction only.
• For helm roof technically it is the same. But I think that if we have name for it name should be in use. It well be easier to chose different shape then defining direction. Especially with auto sniping.
• About factory like roofs i think that "front" should be chosen where it is the longer site of building. Maybe we should find some real live examples for them? --Kendzi (talk) 20:29, 12 February 2013 (UTC)
• http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks

At least we are getting closer to a common solution. :) I still disagree about the "factory" roofs, though. For me, these are essentially the same as the simpler forms repeated a few times (sawtooth is a repeated monopitch and so on). So I would assume that the same direction convention applies. Doing so also has the advantage that the roofs in their basic forms would have axial symmetry to the direction, so there'd be no special meaning of the left/right side for mappers to memorize. --Tordanik 22:34, 19 February 2013 (UTC)

We agree on something, it's little strange :)

To me the question is, IF we introduce some direction element to make it possible to model more complex roofs, if then we shouldn't break it up to some very low level roof modeling style. So, to describe every single face of the roof and the heightlevel using this direction/height elements? --!i! 09:08, 10 February 2013 (UTC)

Maybe it is time to make short summarize:

• we will be use tag roof:direction as default for most simple roof shapes
• roof direction face to building front
• roof direction is by default snapped to best matching wall
• if we don't want snapping we could use roof:direction=begin|end on nodes or/end as part of building relation but then it will be rather a node role like ?roof:direction:begin? | ?roof:direction:end? ??

To do:

• Wiki page for roof:direction tag.
• Agree on others roof shapes. (it may require voice of some other persons)
• Add tag to preset
• Add tag to software

--Kendzi (talk) 21:54, 20 February 2013 (UTC)

How about setting up a combined proposal draft for the roof improvements, that is the roof:direction tag and the additional shapes? We can and should start adding it to our programs soon, but it could formally remain a proposal until other community members have agreed.

Ok --Kendzi (talk) 19:26, 6 March 2013 (UTC)

Even though you have listed it as part of your summary (which I otherwise agree with, including your suggested roles), I'm not yet sure about the snapping. Yes, it should happen if the direction is "quite similar" to that of a wall. But maybe we should not always snap if the direction is very different from any wall, particularly with an exact numeric angle given? Do you have any particular opinion here? --Tordanik 02:54, 4 March 2013 (UTC)

I thing that snapping should work always for word direction description. For numeric values it should be turned off. But interesting problem is adding priority for snapping to building front wall. It is a problem with non rectangular outlines. See images. The both roofs have direction set to S and small change in location of one node --Kendzi (talk) 19:26, 6 March 2013 (UTC)

Here are some other limitation I came across for rather "simple" cases. I can give you a bunch of real-world examples for all of them:

• a roof that has more than 4 edges, but is otherwise pyramidal. See the tower of Klosterkirche Wennigsen for an example. The lower part of the roof could be expressed with pyramidal.
• 2 or more building parts forming shapes like a T or L, both having gabled roofs, where one roof extends until it meets the other. One example is Firestation Wennigsen.
• Buildings that have different roof shapes at ends (e.g. one end gabled, the other end hipped). One example can be found in Wennigsen panorama close to the left end, right of the junction. Could also happen to be mansard or inverse-gambrel (how to tag that?) on one side (not end) of the roof and gabled on the other one. Probably this boils down to be a combined version of the monopitched roof above. I still would like to leave the actual work of finding the middle to the renderer, this makes it so much easier to correct the whole building later instead of having to move all the parts around.
• buildings having e.g. gabled roof, but not symmetrical, i.e. the top is moved to one side of the building. Could also be expressed with 2 monopitched if needed. This is a point where I could accept the need for user splitting the roof, as the renderer can't know where to split.
• roof:direction for buildings having (nearly) the same length and width. This happens easily for e.g. duplex houses. It is hard to decide if the orientation has to be along or across, usually one has to wait for that stuff being rendered and then use the other orientation if it doesn't fit.

Dakon (talk) 10:23, 13 April 2013 (UTC)

facade

• 

  colouring of multiple areas per wall

• 

  Example of possible use two multipolygons and one overlapping way

• 

  non solid material/multiple materials per fascade

Some problems with different colours on the walls of a building, e.g. a house with 4 corners and 4 different colours on each wall, not easy to devide in building:part areas. Or attach the colour to a non closed line? --Aceini 14:55, 5. Feb. 2013‎

Working example of building multiPolygon

It is no problem for vertical changes, simply split outline to multipolygon and tag all walls separately with material. More over this give you chance to tag windows columns on wall. --Kendzi (talk) 04:37, 6 February 2013 (UTC)

It should be noted that this method does not work for shared "wall" ways with different attributes. --Tordanik 09:53, 6 February 2013 (UTC)

Why we afraid of ways lying on another way? If we have two ways we can tag them with different tags. --Kendzi (talk) 21:00, 6 February 2013 (UTC)

It is somewhat unusual as you normally only have ways lying on top of each other when you do not use multipolygons. But it's true that this would work and it could be a good solution in these (relatively rare) cases. So I retract the objection. :) --Tordanik 21:34, 6 February 2013 (UTC)

[[File:AkademicheskiyRyabinina25.jpg|thumb|right|Right facade has horizontal and vertical dividing to parts with different colour|300px]]

• Are there any existing scheme for tagging building with horizontal and vertical dividing of facade to parts with different colours? If we have only horizontal dividing, we can use multipolygons (building:part=yes + building:levels=2 + building:min_level=1 + building:colour=red and building:part=yes + building:levels=3 + building:min_level=2 + building:colour=blue), if we have only vertical dividing, we can tag colours on lines, which form multipolygons (building:colour=red on one line and building:colour=blue on second line). But what can we do, if there is horizontal and vertical dividing (look at right facade of building at photo). We should have a scheme for tagging different colours at different height at one line. Do we have such scheme? If not, what about building:colour=red (the colour of the biggest part of facade - "main" colour) + building:colour:conditional=red @ building:levels=2 ; blue @ building:levels=3 + building:min_level=2 ; grey @ building:levels=5 + building:min_level=3 (which means, that facade at this part of line has red colour from level 1 to level 2, blue colour at level 3, grey colour from level 4 to level 5)? Dinamik (talk) 10:17, 23 September 2013 (UTC)

Is there still no conclusive answer to this problem described by Dinamik, almost 5 years later? --Jarlemag (talk) 16:36, 11 July 2018 (UTC)

For horizontal division (sections of wall that have different attributes), I've previously suggested drawing a wall tagged building:wall=yes + building:colour=*, using the same nodes as the building's outline. That's non-standard, though. Horizontal division can already be achieved to an extent with stacked building parts. Anything else is still beyond what Simple 3D Buildings supports (but you could always upload a model to the 3D Model Repository!) --Tordanik 16:43, 9 December 2018 (UTC)

general

• 

  Balcony

• 

  Pillars

• 

  Passages

• Freeform buildings like the Grazer Kunsthaus: http://de.wikipedia.org/wiki/Kunsthaus_Graz --Aceini 14:55, 5. Feb. 2013‎

Maybe there is a misunderstanding: What S3DB offers is called procedural models (in short: describing geometry and attributes with tags). It's an old story, that this approach is very limited compared to real 3d modelling for different reasons (schema needs to be simple, multiple editor support, entered manually (as VGI) so <10 tags usually, OSM ist 2D, ...). To bring in more detailed models, that usually have only one single instance on the world, please use OpenBuildingModels to contribute an dedicated real 3D model. --!i! 10:20, 6 February 2013 (UTC)

• Buildings with a atrium - multi-polygons! --Aceini 14:55, 5. Feb. 2013‎

Currently this works fine for me. Can you please bring in your case in the forums, please? --!i! 10:20, 6 February 2013 (UTC)

• Churches in general (e.g. colone cathedral is a nightmare) --Aceini 14:55, 5. Feb. 2013‎

IMHO it's still possible (depends on what results you desire). Otherwise use OpenBuildingModels again --!i! 10:20, 6 February 2013 (UTC)

• buildings with cellar half in earth, half above earthline --Aceini 14:55, 5. Feb. 2013‎
• 3D area with heights, e.g.: http://84.115.129.21/gallery3/index.php/OSM/IMAG0246 (height value is strange against surrounding buildings) --Aceini 14:55, 5. Feb. 2013‎

Here seems to be an misunderstanding, too. OSM is about semantics and 2D objects in general and a huge part of the community don't wan't to mess it up with to much data, that can be maintained seperately. This is where OpenDEM comes in (or will), by contributing global 3D height data. Sadly it's currently very limited (no editing, only SRTM resolution, ...) but this is the way how most of us agreed to maintain height level dataset (external). --!i! 10:20, 6 February 2013 (UTC)

I disagree with you here. Datasets like OpenDEM provide rasters for relatively coarse terrain elevation. But local detail like retaining walls, incline of steps etc. has to be in OSM, it cannot reasonably be maintained without the connection to the vector data. So imo this example does at least require some data in OSM (e.g. tagging at which level the entrance is, the incline of the footway that leads to it and so on). --Tordanik 10:59, 6 February 2013 (UTC)

You are right, ok for hyperlocal height changes (as channels or ditchs that result in a pulling down, this is ok. Maybe we can introduce similar elements for pulling down earth around cellar etc. But we should make clear, that OSM is not 3D in general and that we don't want to flood our towns with big height level elements. There are better technologies to model the earth surface outside OSM, as OpenDEM for example.--!i! 08:01, 8 February 2013 (UTC)

• buildings with a bevel facade(http://www.panoramio.com/photo/8938906)Hedaja 23. February 2013

The state of 3D buildings

Hi guys, what is the state of this project? From my observations in JOSM and the WikiMiniAtlas I can only conclude that it is quite confused. The page mentions demo areas, such as Karlsruhe. I see a bunch of buildings with key=building:roof:shape rathe ran key=roof:shape like the instructions mention. What is the appropriate key? Also the bulk of buildings that is tagged with a roof shape (in Karlsruke and heidelberg) does not have either roof:height building:levels or height tags. This makes them basically unusable for 3D rendering (unless you want to make up data by assuming default heights, which I personally think is a terrible idea). --Dschwen (talk) 18:33, 14 February 2013 (UTC)

The page "Simple 3D Buildings" describes what we, a group composed primarily of 3D developers, want to standardize on as a lowest common denominator - but we are not there yet. For example, we would like to ultimately have only roof:shape keys in the database, but today there are still at least as many building:roof:shape around. So it might be a good idea to treat all the building:roof:* keys as synonyms for roof:* for now - and maybe building:height as a synonym for height.

Demo areas aren't provided by ourselves, but are usually added by local mappers. We haven't verified that they conform to Simple 3D Buildings. It's probably something we should do, though.

Providing the height or the number of levels is of course part of mapping a building completely, but it's not always easy for mappers: Roof shapes are visible from aerial imagery, whereas height/building:levels often requires visiting a building in person. So it's not unsurprising that roof shapes may sometimes show up before heights. Personally, I do indeed "make up" data by assuming default wall/roof materials, a default roof shape (flat) and and a default height instead of waiting until all that data is available for a building. My goal is to reward mappers for each step by doing so. I think most other renderers also assume defaults, but the choice is yours of course. (By the way, this is also why I didn't expect that the definition of height the height tag on building outlines could have implications for the need to detect building parts before you wrote about it - those who assume default heights couldn't use your intended workaround anyway.) --Tordanik 20:47, 14 February 2013 (UTC)

Material and colour

Hi, I didn't found out, what the default solution is, if the tools render an building that has an building:material=* and an building:colour=* tag. My interpretation is, that this should result in a somewhat multplied texture. So if you want to express, that there are bricks, but more yellow looking ones, you just need to use both tags. What does you say? --!i! 23:26, 16 February 2013 (UTC)

If there is no color setup, I render texture. If color is setup I multiple color with texture converted to gray levels. --Kendzi (talk) 05:56, 17 February 2013 (UTC)

My solution is similar. I think that blending a grayscale texture with the tagged color is indeed the expected behaviour. --Tordanik 12:01, 17 February 2013 (UTC)

I don't want to abuse this as a bugreport platform but the "latest build" doesn't seem to blend textures with the specified colour. A building tagged with "building:material=wood" and "building:colour=red" just displays the grey wood texture. Similar a building tagged as "building=garage" and "building:material=wood" doesn't use the wood texture but the garage teture. The latter case may be more difficult to handle though but it would be nice to see the first case handled correctly :). --Scai (talk) 16:49, 17 February 2013 (UTC)

That's not a flaw in the software but in the default render style. I simply haven't created grayscale textures for all materials, and as a result those materials are not marked as "colorable" in the config file yet. In some cases (bricks) it would also be necessary to separate the original texture into two layers because only some parts of the texture should be colored. --Tordanik 16:56, 17 February 2013 (UTC)

Ok this explains my confusion. Now I know I'm still tagging the "right" way :) --!i! 11:13, 18 February 2013 (UTC)

Thanks, for clarifying. How about dual colour textures? e.g. for timber_framing, we'd need one colour for the frames (default: brown), and another for the fields (default: white); currently, neither is rendered as I can tell. (Is it possible by the way, that heights of building parts are altered while viewing a model from within JOSM?) --RalfG (talk) 14:54, 18 March 2014 (UTC)

Tunnels through buildings

Hi, at least OSM2World creates real tunnels (so drilling a way into -1 layer). Is there currently any agreement, how usual footways thorugh buildings (so on the same height all the time) can be mapped? --!i! 11:14, 17 February 2013 (UTC)

There is probably no agreement yet, but I'm interpreting the proposed tunnel=building_passage as a tunnel through the building. OSM-4D has tunnel=passage for the same thing (OSM-4D/3D building/tunnel), but it is used less often. In some cases with wide and recangular-shaped tunnels - such as the right example image in the building_passage proposal -, building parts for the building and covered=yes on the way might be an alternative. --Tordanik 12:11, 17 February 2013 (UTC)

What shapes of tunnels are implemented in OSM2World? --Kendzi (talk) 21:53, 20 February 2013 (UTC)

OSM2World currently does not distinguish between tunnel shapes, unfortunately. T01 is used for all tunnels. --Tordanik 23:05, 25 February 2013 (UTC)

How to name roof tunnels described by codes: T01, T02 ... --Kendzi (talk) 21:53, 20 February 2013 (UTC)

Putting things on buildings

Hi, is there already an idea, how with S3DB we can e.g. put mobile base stations on the top of a building, or adding street lamps on parking decks? --!i! 21:39, 22 February 2013 (UTC)

Perhaps using, min_height and height, the same as trees in above example? --Kendzi (talk) 21:46, 22 February 2013 (UTC)

min_height=* sounds reasonable, but on the other hand we don't want to specify any height related things. I was thinking about level=* or ele=* or something related? --!i! 21:53, 22 February 2013 (UTC)

level=* and min_height=* sounds good. I don't like tag ele. It mean height above sea level and it will be hard to measure. It is better to assume that all building parts will use height, min_heigh and levels tags. And it will be only one connection to ground level in one parts group. By parts group I mean all building object connected by relation type=building. --Kendzi (talk) 08:45, 23 February 2013 (UTC)

I'm not sure whether min_height is a good idea here. One part of that is that it's not clear to me whether our definition of height for buildings and building parts also applies to features on bridges and roofs, as you suggest for #Trees - I suspect that a mapper may not expect that and it has some practical drawbacks. Even if it does, it won't work if you do not know the height of the building. So a level-based solution appears like a better choice - or maybe a special tag like location=rooftop? I'm not quite sure myself actually. Adding it to the relation seems like a good start, though. --Tordanik 23:35, 25 February 2013 (UTC)

FWIW, I've used location=rooftop on antennas. Seems location=roof is atm more popular, but the numbers are just 25 vs. 40. I believe it was me who added the two instances of location=rooftop_wall, too. The last one is where it's really, really close to the roof, but still "on the wall". Or maybe it was a part of the roof that lies above the roof level of the rest of the building, so there's a wall in the middle of the roof... Alv (talk) 08:10, 26 February 2013 (UTC)

Roof and underground levels

When is a level considered are roof:level compared to a building:level? For now I used the rule "if the floor of the level is within the roof it's a roof level". This will probably give no false positives, but will it miss something? The same applies to underground levels. --Dakon (talk) 22:23, 13 March 2013 (UTC)

Outline height tag conflicts

All general tags should be added to the outline, I guess this includes 'height' for the whole building. The problem is how to use the outline for rendering (with building:part=yes) but with a different height? E.g. the height of a church is usually the height of its towers should one then duplicate the outline to render it with a different height? And if so is there a way to do this in JOSM comfortably? :) Jeffdameth (talk) 14:07, 1 April 2013 (UTC)

From what I know a tag will be added to the outermost line where it makes sense. So for your church example you would put the height only at the buildings parts as you usually don't have a uniform height. Things like building:colour then still may be on the building. YMMV. Dakon (talk) 14:53, 1 April 2013 (UTC)

I mean the building outline holds general properties like name and the overall height is also a property of the whole building. The problem occurs when the outline should also be rendered as building part with a height that differs from the overall height. As the height tag is already widely used for describing the overall height I would suggest that either building:part:height or building:height(which might be confusing) could be used to override 'height' for 3d rendering --j3d (talk) 12:11, 11 May 2013 (UTC)

I think adding new tags complicate simple things. Why exactly in this situation you don't want to convert this way into two multipolygons? One of them became container for all tags from outline, like overall height, name and all others “2D” tags. Second will include only tags from building part, like height of part or roof shape. Both of them will have the same way without tags as member with role outer. Naturally you need to add this two multipolygons as members of relation type=building ;) --Kendzi (talk) 20:44, 12 June 2013 (UTC)

It would be nice to have some more examples, such as for churches with a dome or tower in the middle. It would also be helpful to see how to tag the "normal" tags on these buildings.Neuhausr (talk) 20:08, 2 September 2015 (UTC)

Help with multipart buildings

How do i correctly map these kind of buildings when the physical building is split up in multiple building shapes (one for each address)?

• Picture on Bing: http://binged.it/111JDR0
• On OSM: http://osm.org/go/0JhMwjhOd--
• Relation for building: http://www.openstreetmap.org/browse/relation/2875495

I have mapped all the building parts with building:part=yes and roof:shape=hipped. Is this correct, or has the roof:shape=hipped to be added to the relation instead of the individual buildings?

--Flaimo (talk) 16:37, 13 April 2013 (UTC)

i tried the Kendzi3D plugin in josm. besides the fact that it crashes as soon as i do an edit, it seems that it doesn't render the roof shape correctly since it renders it for every building part individually instead of treating all parts as one single building. --Flaimo (talk) 18:20, 15 April 2013 (UTC)

when you split this building on individual part it is no longer hipped roof. So middle parts have gabled roof --Kendzi (talk) 05:35, 16 April 2013 (UTC)

can you provide some information about crashes? best on github? --Kendzi (talk) 05:35, 16 April 2013 (UTC)

1) crash was the wrong word. actually josm just freezes and i have to kill the process (mac os x snow leopard). are there any logs written somewhere that i can send you?

2) ok, that means i have to add "hipped" to the building parts at the end and the ones in the middle get a "gabled"? what kind of roof shape to i have to map for corner buildings? (in my example house number 33)? personally i think, that additional tags in the relation should be evaluated and applied to the building as a whole (treating all parts as if it was one single building). this would make mapping buildings like my example a bit easier, especially if there are a lot of buildings to map. --Flaimo (talk) 07:56, 16 April 2013 (UTC)

after I mapped my first patch of buildings I have the following questions/suggestions:

a) How do I map L shaped buildings with a gabled or hipped roof correctly?

b) Follow up question: Are the keys roof:edge, roof:apex, roof:ridge used in such a case? If yes, how? Could you please add documentation for them to this page?

c) Farm buildings mapped as multipolygons (German "Vierkanter") are not rendered correctly as soon as building tags are applied to the outer area. Example: http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=48.25764&lon=14.26895&layers=B0TTFF. where should the tags be applied to render correctly? (again problem with hipped roofs)

d) I still haven't figured out how to map the buildings stated out in my original posting in this sub topic. How to I correctly map one big physical building split up into several logical building areas because of house numbers? Should building and roof keys be applied to the building relation and are those evaluated correctly?

e) How do i map this special kind of building?: http://binged.it/11BszD7 The biggest level is the second one. The first and third one are smaller in size. So far I haven't had any luck on getting it rendered correctly with two building:part areas: http://www.openstreetmap.org/browse/way/42743080

f) Suggestion: amenity=parking_space should be rendered. The surface value can be determinated from the relation the parking space is part of. If the surface key is missing in the relation or it isn't part of an relation, the default value should be asphalt. if the parking space has a surface tag applied directly to it, this one should be used instead.

--Flaimo (talk) 21:32, 23 April 2013 (UTC)

Additional roof:shape value needed for bend roofs

I don't know what the correct english translation for these kind of roof shapes are, but i see these quite often: http://www.burn-in.at/sites/default/files/styles/page_news_main_img/public/news/Design%20Center%20Linz.png?itok=x7SmcF1L

could you please add support for this kind of slightly bend roof shape? --Flaimo (talk) 08:00, 16 April 2013 (UTC)

Is that the same shape we temporarily call roof:shape=round - "5.0" in OSM-4D numbers - or is there a difference?

--Tordanik 09:30, 16 April 2013 (UTC)

that is exactly the shape i was looking for. so it only needs to be documented? or is it still unofficially supported? --Flaimo (talk) 10:26, 16 April 2013 (UTC)

It needs to be documented, yes, and of course we still need to make sure that there are no objections. An implementation in OSM2World is already available. --Tordanik 10:43, 16 April 2013 (UTC)

I am not sure if "round" is the right name. A dome is round as well :-) But i do not find a better word --Zuse (talk) 11:18, 16 April 2013 (UTC)

The word used in architecture ist "arched". See dict.leo.org EvanE (talk) 11:42, 16 April 2013 (UTC)

If that is proper terminology, then it might make sense to switch to "arched". Is the roof shape:value supposed to distinguish between different curves (circles, other ellipses, parabolas, ...)? Or would we map that as a subtag, if at all? --Tordanik 19:07, 16 April 2013 (UTC)

'barrel' is the name used in IFC specification for roof types http://en.wikipedia.org/wiki/Barrel_roof http://www.buildingsmart-tech.org/ifc/IFC2x4/rc2/html/schema/ifcsharedbldgelements/lexical/ifcrooftypeenum.htm --Jeffdameth (talk) 21:26, 1 May 2013 (UTC)

this shape is not supported by kendzi3d. But it will be. So no objection from me. How it should behave when roof height is bigger then building width? --Kendzi (talk) 12:43, 16 April 2013 (UTC)

That's a good question and we weren't really sure about this during implementation in OSM2World, see the discussion for the pull request. --Tordanik 13:04, 16 April 2013 (UTC)

I think we need another simple scheme tag for "hipped-round" or "dome with ridge" shape like The Grand Palais Cmif4 (talk) 11:18, 28 November 2013 (UTC)

Too complicated description of building outline rendering

There is still a <TODO> tag for the explanation, anyhow from what I understand it does state that 'building outline will not be considered for volume rendering when it contains a building part'. The way described to include the building=yes way in the outline sounds too complicated to me. Infact the relation is ignored by osm2world and kendzi3d does not rely on the relation. Both render building=yes anyway (osm2world subtracting building:part areas) [edit: testing with the latest kendzi3d, it does use the relation, but seems to ignore role=outline (there are also few examples where role=outer was tried instead)]. There are alreay quite a few buildings tagged for the renderers, i.e. missing the relation or not having all building:part(s) required to fill the complete outline that is intended for rendering.

A simpler approach would be to use building:part=no on the building when it should _not_ be considered for volume rendering and building:part that overlap 'building' are subtracted from the 'building's area. This would lead to much easier tagging (less error prone) and does have the same expressiveness.

Comments or suggenstions? --j3d (talk) 13:55, 12 June 2013 (UTC)

As I see it building outline (ways with tag building=*) always should not be rendered when building parts exist (ways with tag building:part=*). I see outline as object which is always bigger then set of all its parts. So all parts are always inside of outline. So outline should always be hidden when parts are rendered. --Kendzi (talk) 20:27, 12 June 2013 (UTC)

Ok, I've updated the Wiki description to make the current handling more clear. Could you check if it matches your interpretation. IMO it would be still much simpler if there would just have the single option to use building:part=no on the building=* to disable using it for 3D rendering. --j3d (talk) 15:25, 14 June 2013 (UTC)

I would like to remand that OSM is not only database for 2D or 3D rendering. Adding tag building:part=no will simplify rendering task. But it don't give you connection between outline and all parts witch create building. Kendzi

Currently Kendzi3d check only tags on ways/multipolyon re is ignored. --Kendzi (talk) 20:27, 12 June 2013 (UTC)

Pyramidal roof type

There are currently two diverging interpretations for roof:shape=pyramidal[3]. I think we could make interpretation of 'pyramidal' computational tractable by defining the possible ways how to construct 'pyramidal' geometries and see which name fits best. Currently I can think of:

* square_pyramidal as:
1. take the minimal object orient bounding box(oobb) of the outline, 
2. if oobb is not unique roof:direction is required to pick the box that matches the intended direction. 
3. connect edges from center (of oobb) to all outline points and interpolate point height between center and oobb.

* pyramidal: 
1. take the convex hull of the outline
2. connect edges from center (of convex hull) to all outline points and interpolate point height between center and convex hull.

* tented:
1. connect edges from center (of convex hull) to all outline points.

tentend and pyramidal produce the same result if outline is convex. square_pyramidal and pyramidal produce the same result when the outline is a rectangle --j3d (talk) 20:52, 12 June 2013 (UTC)

It seems 'tented' requires that a line from center to outline touches the outline only once, see Pyramidal_interpolate. Otherwise one would have to remove those segments of the outline that intersect with with a line from center to outline to get a 'planar' roof.--j3d (talk) 00:28, 14 June 2013 (UTC)

I hope that by pyramidal interpolation of middle points you mean something like this:

--Kendzi (talk) 22:00, 13 June 2013 (UTC)

Yes, this looks to me like the result I would expect from the steps for 'pyramidal' --j3d (talk) 23:18, 13 June 2013 (UTC)

I like this definition. I added them to Kendzi3d v190. --Kendzi (talk) 21:07, 14 June 2013 (UTC)

Nice -- As 'tented' and 'square_pyramidal' are not in S3DB I wonder what in general would be a good way to map these (not yet standard) tags and allow renderers to fallback to standard types. One way would be to interpret e.g. roof:shape=tented;pyramidal as list from more to less specific types. --j3d (talk) 10:00, 19 June 2013 (UTC)

I don't think that lists are good idea. I think that better is to add some other tag for alternative roof presentation. For example in my application you can override value from roof:shape by using tag 3dr:type. Another thing is that application should decide how to handle not supported roof/tags. So if application don't support tented roof it can decide to render it as pyramidal or flat roof. talk)

The problem is that when adding new roof:shape types every renderer not supporting it has to be updated to know what the appropriate fallback would be. I think it would be a good way to allow using more specific types while still having renderers that dont support the latest proposed tags to work as before. So this would require modifications how to handle roof fallbacks only once and would allow continous transition to more specific tags (say tented as part of S3DBv2). For now I would not use 'tented' as long it cannot be handled by other renderers --j3d (talk) 11:16, 19 June 2013 (UTC)

I think that coma separated list is the worst choose. Most application read tag value and compare to some string. So if you put list they don't find any of values. Much better idea is to use additional tag. But I think that application should chose what to do when some shape is missing. We could only define some wiki page with advice how it could be resolved. Eg if shape square_pyramidal is missing map to pyramidal or like on this table. --Kendzi (talk) 16:01, 19 June 2013 (UTC)

I'm not fond of any solution that burdens mappers with handling fallbacks, neither comma-separated lists nor multiple tags. Generally, I think that fallbacks are something best handled in individual applications, and it's not really that much work. But if there is demand for a generic way of handling fallbacks, I could get behind the idea of a centrally maintained fallback recommendation table that could then be applied automatically by applications if they encounter an unknown tag with a defined fallback. --Tordanik 16:08, 19 June 2013 (UTC)

fallback is not the proper term here I guess, it's for allowing more specific/experimental roof:shape to be added without conflicting with the work of previous mappers that expect their roof show up in their renderer as they edited it. - If the roof does not show up because someone changed it to a not-yet-standard tag I can imagine how things turn out :) So asking developers once to treat roof:shape as a list is something simple to implement and does not require maintanance of a central roof:shape ontology --j3d (talk) 05:32, 21 June 2013 (UTC)

That problem is in no way specific to roof shapes, though, and we generally accept that there is a transition period during the introduction of new values. If the introduction is handled cautiously (first use on new buildings only and document - at which point a suggested "fallback" can be established -, then start replacing existing values) it can happen without noticeable disruption.

What I dislike about your suggestion is not the effort to implement it, which is trivial. The problem is the impact on the mapper community. Mappers should not have think about applications' needs much, they should just try to describe reality accurately. The suggested list of values breaks with that principle, as it would not tell us more about the real world than using only the most specific value. --Tordanik 09:55, 21 June 2013 (UTC)

Usage of Mansard

May be it is not implemented to add a height value of the mid-level of a mansard roof. Is there any? I need such a tag, because the building_part-relation is not supported.

why relation is not supported? --Kendzi (talk) 17:02, 13 June 2013 (UTC)

in roof table there is parameter 3dr:height2 for mansard roof. You can test it in Kendzi3d. Maybe it should be found some better name for it. --Kendzi (talk) 17:02, 13 June 2013 (UTC)

Defaults

My (personal) experience from the growing number of tools (partial) supporting S3dB, I noticed that we need to talk about default values and interpretation algorithms in a second step. This includes colours, heights, building:part computations, shapes, esp. when some attributes are missed. --!i! 11:56, 20 June 2013 (UTC)

In my opinion usage of colors should be treated as a hint by the renderer and the actual rgb codes left up to the designers choice to match the overall style in saturation, tone, etc. Or would you expect all maps to render asphalt roads in black?

+1 for algorithmic description to determine roof shapes. bonus points for proper definition including constraints that could be checked by an editor plugin :) --j3d (talk) 05:59, 21 June 2013 (UTC)

Balconies

I suggest to use the tag building:part=balcony for balconies, especially for 3D views of the map. We could use this tag for balconies in association with building:part=balcony

levels_count=6

levels_height=2.5

min_height=5

colour=white

what do you think about ? Currently in France the balconies are rendered with the tag Tag:wall=no which is not precise. Otourly (talk) 15:34, 25 July 2013 (UTC)

• in Kendzi3d you can repeat building parts using clone:height relation. Some talk how it work and examples was added here: http://forum.openstreetmap.org/viewtopic.php?pid=206061#p206061 --Kendzi (talk) 17:44, 14 November 2013 (UTC)

Recent edits regarding building outline

I want to discuss some of Dinamik's recent edits. This one presents valid arguments against the option to combine building:part=* and building=* on the same way. But I do not like to have a long essay describing that issue. Instead, I would prefer to remove this option from the page entirely - there is no situation where it can really be used properly for a building with more than 1 building parts according to these arguments. Does anyone disagree?
There was another edit regarding the building outline here, but I do not understand what it means. Especially "both as along horizontal, as along vertical axis" and the word "imbricated" are unclear to me? Dinamik, can you clarify? --Tordanik 11:23, 17 September 2013 (UTC)

About combination of building=yes and building:part=yes. I see only one case, when building=yes and building:part=yes can be in one object - if building consists from one building:part and building equals to this building:part. I saw, how editors added tag building:part=base to building=yes, because some renders didn't show volume of building, if building touch some building:part - so there were problems with rendering of indivisible buildings, which touched the buildings, cutted into parts. Dinamik (talk) 17:53, 17 September 2013 (UTC)

if it is a problem with render why not to add issue to this render? --Kendzi (talk) 18:23, 17 September 2013 (UTC)

I didn't want to say, that adding building:part=base to solve problems of some render is good idea, I just wanted to mark, that the only case, when building=yes and building:part=yes can be in one object, is when building consists from one building:part and building equals to this building:part. Dinamik (talk) 21:28, 17 September 2013 (UTC)

About imbrication of buildings. I think, that tagging, when there is a part of space, which belongs to several buildings, is incorrect. Projections of different buildings to some planes can be overlapped (because one building can have height from 0 to 5 meters and another can have height from 10 to 15 meters), but not parts of building (in volume).

About this edit - I also agree, that projections of building:part-s to horizontal plane can be overlapped. But, as I said, I think, that is incorrect, when one part of space belongs to several different building:part-s. For example, situation, when part of space belongs to building:part with building:level=5 and building:part with building:levels=7 + building:min_level=3 is incorrect (because part of space between levels 4 and 5 belongs to different building:part-s. How can we interpret such situation? Another example, two building-s with building:levels=2 and building:levels=3 overlapped - how can we interpret this?

About "both as along horizontal, as along vertical axis". I wanted to say, that, for example, if building:part-s, which belong to building, have levels from 1 to 10, building also should have levels from 1 to 10 (to "cover" projections of building:part-s to vertical plane), if projections of building:part-s to horizontal plane cover some area, building show cover this whole area too.

My English is not the best - so if someone can write my ideas (if they have sense) more properly - please, do it. Dinamik (talk) 17:53, 17 September 2013 (UTC)

It could be easier to understand if you make some example images --Kendzi (talk) 18:23, 17 September 2013 (UTC)

I've tried to do some image fastly. Please, be not very strict to its quality. We have two parallelepipeds: AFGBDIHC and KORLNPQM. There is an imbrication: part of space KVXYZWHE belongs to both parallelepipeds. We should tag buildings in such way, when there is no imbrications of different buildings and different building:parts. Dinamik (talk) 19:32, 17 September 2013 (UTC)

We've had a [4](brief discussion) with Dinamik (talk) on local forum yesterday so I'll try to clarify and explain a bit. The question is: Could building:part-s intersect with each other in 3D or they have to be just aligned without intersection? Dinamik (talk) says that for the more strict order there must be no intersections between building parts. And his arguments now seem clear and clever to me. But that also overcomplicates 3D model alot. The big problem with intersecting building:part-s we'll gain when trying to render overlapping textures for different building:material-s or building:colour-s. See the picture:

Term overlapping usually in OSM is referring to 2d areas. So if you referring it to 3d block it is different story. If we would like to do more complex models we need to add in 2d space several areas one over previous. But current definition of S3DB is quite clear that buildings are build from solid "boxes" and people should avoid overlapping them in 3d space. Overlapping should be forbidden only in case when two solid boxes share common wall. In this case we have z-buffer fight for wall texture. In other cases it is not so important and should be only not advised. --Kendzi (talk) 09:52, 18 September 2013 (UTC)

"But current definition of S3DB is quite clear that buildings are build from solid "boxes" and people should avoid overlapping them in 3d space" - I think, this thing is not so clear, because it became an object of discussion (the was a discussion about possibility of overlapping in 3d space). "Overlapping should be forbidden only in case when two solid boxes share common wall. In this case we have z-buffer fight for wall texture. In other cases it is not so important and should be only not advised" - I want to add also two another situations: if two solid boxes share common roof, we can have problems with roof structure, if two solid boxes share common floor, we can have problems with floor structure (imagine part of building with building:min_level (or min_height), where "floor" is seen from the outside and, so, can have such attributes as material and colour). I propose to write something like "When "dividing" into building:part-s buildings are build from solid 3d-"boxes" - you should avoid overlapping them in 3d space. In case when two solid "boxes" share common wall, overlapping is forbidden, because it may lead to problems with interpreting of wall attributes. Cases, when "boxes" share common roof or floor, are analogous. In other cases it is not so important, but, in any case, overlapping is not recommended". Dinamik (talk) 10:22, 18 September 2013 (UTC)

Perhaps we could put a shorter text with the same meaning on the page? My suggestion: "Avoid using building:parts with overlapping 3D volumes if possible, especially if the volumes would have common faces". --Tordanik 19:51, 18 September 2013 (UTC)

I like your text. Dinamik (talk) 09:10, 21 September 2013 (UTC)

• "There are three ways to use the area of building=* for 3D Rendering in this case: ... Use building:part=yes only for those parts, which differ from the overall building." I think, that, as we were talking ealier, there is only one case, when building=yes and building:part=yes can be in one object - if building consists from one building:part and building equals to this building:part. So, indeed, phrase "Use building:part=yes only for those parts, which differ from the overall building [to solve the problem with 3D-rendering of whole building]" also doesn't have special sense, because we in any case should use building:part=yes only for those parts, which differ from the overall building (because part can equal to building only if building consists only from this part and only in this case building=yes and building:part=yes can adjoined). Dinamik (talk) 09:36, 21 September 2013 (UTC)

So is there any reason not to delete the first of the three ways? --Tordanik 10:25, 30 September 2013 (UTC)

I would prefer to keep the first way because it allows to describe the same cases as the third way without using relations. Of course 'height' of the outline needs to be interpreted as height of the part and not the whole building. - If the maximum height of the building differs from the outline-part *and* the overall height should be attached to the outline, then I would suggest to differ between the tags 'height' as interpreted for volume rendering and 'building:height' for the overall height.--j3d (talk) 18:39, 7 October 2013 (UTC)

I'm not sure whether I like that - it's a hack, but of course avoiding relations is a tangible benefit. What would you suggest for the overall levels? --Tordanik 12:42, 8 October 2013 (UTC)

One more try :) -- height, min_height and levels could be used without prefix when the context is not ambigiuous. Otherwise use explicit building:levels and building:part:levels --j3d (talk) 03:02, 9 October 2013 (UTC)

Ok... How about making things consistent and only keep the second option. The third option has the same issue as the first regarding inconsistent use of tags for the role:outline part. --j3d (talk) 17:40, 22 October 2013 (UTC)

Floor

I propose to add text about "floor" material and "floor" colour. When building have min_level or min_height attribute and "floor" is seen from the outside, it has sense. Tags: floor:material and floor:colour (analagous to roof:material and roof:colour). Dinamik (talk) 10:24, 18 September 2013 (UTC)

both tags are suported by kendzi3d (unknown, asphalt and marble) but currently there is no list with materials for floor:material=*. Could you prepare it the same way as it has been done for building:material=*? --Kendzi (talk) 18:29, 18 September 2013 (UTC)

I'm not sure whether "floor" is the best term, actually. It makes me think of the surface you walk on indoors. Could there be some better word for the underside of a building? --Tordanik 19:20, 18 September 2013 (UTC)

I understand potential wrong beliefe, which you said about, but I couldn't contrive better word. Dinamik (talk) 09:02, 21 September 2013 (UTC)

How about bottom:material? --Tordanik 20:02, 23 September 2013 (UTC)

I think, it is good idea. But we should try to take into account other opinions and fact, that floor:material is already in use Dinamik (talk) 20:49, 23 September 2013 (UTC)

But in this case we should name roof:material rather top:material... --Kendzi (talk) 20:33, 23 September 2013 (UTC)

I made some draft. Dinamik (talk) 09:02, 21 September 2013 (UTC)

I think that this is misleading. I would like to reserve floor:material to actual floors, e.g. of a shelter_type=lean_to.--PangoSE (talk) 12:47, 15 January 2020 (UTC)

This discussion is continued in Talk:Key:floor:material#Suggest renaming. – Minh Nguyễn ^💬 19:49, 17 October 2021 (UTC)

Frustums

• 
• 
• 

Are there any existing schemes for tagging frustums? How can we tag, that shape is, for example, pyramidal, but upper part of pyramid is cutted? Note, that we also should have tag for material and colour of upper plane (because they can be different from material and colour of side planes). If no, what about roof:shape=pyramidal, roof:height=6, roof:top:height=9, roof:top:material=brick (this means, that if pyramid is not cutted, it has height 9 meters, but part over 6 meters height is cutted and upper plane has brick material)? Dinamik (talk) 07:59, 23 September 2013 (UTC)

it looks like this roof: http://wiki.openstreetmap.org/wiki/File:MarekRoofType9_2.jpg --Kendzi (talk) 20:30, 23 September 2013 (UTC)

Yes, it does. But I don't see transparent tags for such type. 3dr:type, 3dr:height1, 3dr:height2, 3dr:heightX, 3dr:lenght1, 3dr:lenght2, 3dr:lenghtX, 3dr:dormer, 3dr:donor:type, 3dr:dormer:width, 3dr:dormer:heightX, 3dr:dormer:lenghtX are too complicated. I think, that we tag such cases easier: by tagging "base" of roof and marking height on which we should make cutting. Dinamik (talk) 20:38, 23 September 2013 (UTC)

we need only nice name for this roof to put inside tag roof:shape (maybe frustum?), roof:height we have for height, roof:angle for angle, for top surface we could use top:material and top:colour, so what we need more? --Kendzi (talk) 20:47, 23 September 2013 (UTC)

the base for this kind of roof is this roof: http://wiki.openstreetmap.org/wiki/File:Roof9_0.jpg unfortunately we don't have definition for this roof in S3DB. We need some name for it. --Kendzi (talk) 20:52, 23 September 2013 (UTC)

If the base of pyramid is square, it is easily understandable, what is roof:angle, but if we have just rectangle, we can't immediately say, about which angle we are talking about (because there are 2 different angles). In more complicated shapes it is more complicated - about which angle can we say in case of truncated dome or round roof? I support creating type roof:shape=frustum, but think, that we should have easier way to describe it: we, indeed, describe the base structure and after it add only one tag, which shows height in which our roof is truncated (roof:top:height or top height - the height of roof, if this roof is in our mind not truncated). So I propose to work with roof:shape=frustum (type of roof) + (as an example) roof:base:shape=pyramid (base structure) + (as an example) roof:base:height=9 + roof:height (standard height). If saying another words: I think, that it is easier to describe base structure and after that mark the height of truncating plane, than describe frustum with roof:angle. In frustums it is easier to define by eye foundation, upper side, height between them and exact height of top of figure, if we think, that roof is not truncated, than some angles. Dinamik (talk) 21:24, 23 September 2013 (UTC)

nice thing about roof 9.0 and 9.2 is that all angles of surfaces are the same. Roof 9.0 used with rectangle will generate not pyramidal but hipped roof. So in this case we can easily switch between angle and truncated height.--Kendzi (talk) 16:16, 24 September 2013 (UTC)

I've just now realized assumption "All roof faces of the building with the beginning in the same height, have the same inclination". Yes, in this case height, roof:height and roof:angle are sufficient. Well, we are close to proposing this type as roof:shape=frustum (if we see, that this name is bad, we'll change it) and its tagging with tagging height, roof:height, roof:angle, top:material and top:colour. But a question: how can we tag different colours of sides ()? Dinamik (talk) 18:58, 24 September 2013 (UTC)

If holes were permitted in roofs, frustums reduce to the pyramidal case. I.e. the lower part of the frustum is cut at the inner ring of a multipolygon representing the lower part of the frustum. The upper part of the frustum is tagged (re-)using the closed way (.. that is also the inner ring of the multipolys' lower part of frustum). This way you do not have to invent new tags, height=*, roof:height=*, roof:angle=*, roof:material=*, roof:colour=* suffice, lower and upper part are tagged seperately. height=* for the upper part may be deduced by adding roof:height=* to height=*-value extracted from the multipoly (.. that the closed way is member of as role inner). It also gives more flexiblity when upper part is offset (or inset) against lower.

Example lower part of frustum first, upper part second (height of upper part explicitely given):

• type=multipolygon building:part=yes height=30 roof:shape=pyramidal roof:shape=frustum roof:height=3 roof:material=metal
• building:part=yes height=33 roof:shape=pyramidal roof:height=1 roof:material=roof_tiles

OR, if there is another level between bottom and upper part (offset):

• building:part=yes height=36 roof:shape=pyramidal roof:height=1 roof:material=*

OR, if there is a daylit, open space, (inset) to where the upper part would be:

• building:part=yes height=30 roof:shape=flat roof:height=0 roof:material=grass

--Cmuelle8 (talk) 17:23, 25 September 2013 (UTC)

it is some over-round but it is not the same. roof:shape=9.2 have const all angles (to walls), roof:shape=pyramidal have one common point and all roof surfaces have different angles. --Kendzi (talk) 19:34, 25 September 2013 (UTC)

Yes, you're right, the lower part doesn't have to reduce to the pyramidal case, it could, for certain cases of frustums. Nevertheless, main point remains - tag frustum with an inner ring and reuse/tag the inner ring as a seperate roof-part (which could again be a frustum or pyramid). I corrected the mistake above, see tag after striked-out one. My main issue is not introducing new *:top:*=* for upper part, it can be handled seperately and gives more flexibility this way, e.g.

• frustum + flat top (note: flat top tagged seperately if differen color, material, etc.)
• frustum + pyramidal top
• frustum + frustum + pyramidal top
• frustum + gabel top
• frustum + offset gabel top
• --Cmuelle8 (talk) 19:40, 26 September 2013 (UTC)

Outstanding roof

• 

  roof without "volume" under it: building:part=roof + roof:height=3 + roof:min_height=2 + roof:shape=round

• 

  outstanding roof

• 

  outstanding roof: roof:height=3 + roof:min_height=2 + roof:extent=1 + roof:shape=gabled

Are there any existing schemes for tagging roofs, which consist only from its surface (don't have volume) and outstanding roofs? How can we tag, that roof doesn't have volume? Perhaps, roof:volume=no? How can we tag, that base of roof is lower, that minimal height of volume under roof? Perhaps, something like roof:shape=round + roof:height=5 + roof:min_height=4 + roof:bottom=3 (means roof's base is at 3 meters, roof's top is at 5 meters, but there is no volume under 4 meters)? Dinamik (talk) 19:23, 23 September 2013 (UTC)

There is Tag:building=roof, we could create building:part roof in the same way. As for "outstanding roofs" (I assume this means roofs which extend beyond the building below?), using roof:extent was suggested e.g. here. --Tordanik 19:37, 23 September 2013 (UTC)

Well, it is proposed to use building:part=roof (or building=roof) for roofs, which have only its surface (without volume) and roof:extent for extended distance. Dinamik (talk) 20:15, 23 September 2013 (UTC)

Should an outstanding roof be included in the building outline of a type=building relation? There are less obvious cases than the above, e.g. where a roof extends but not over the whole length of the roofs edge - e.g. where a carport extends the roof, has no volume under it, but is otherwise of the same material and of the same slope of the roof it extends. --Cmuelle8 (talk) 17:38, 25 September 2013 (UTC)

Necessary parameters

I think, that we should add to table with roof:shape with base simplest shapes (basic shapes, which can be tagged without specific complicated relations or/and marking some point as "start points; exception is skillion shape - we should think about its simple tagging) necessary parameters and write, if some of them have default value. I propose to give tags human-recognizable names. Please, leave comments. I'm not sure, that all english terms, which I wrote, are the best. Perhaps, there are other mistakes. Please, note, that table can be changed in the future during discussion. Dinamik (talk) 08:13, 25 September 2013 (UTC)

Image
roof:shape	flat	skillion	gabled	half-hipped	hipped	pyramidal	gambrel	mansard	dome	onion	round	frustum
Necessary parameters	-	roof:height and direction (which tags? roof:direction? what to do in more complicated cases?)	roof:height and roof:orientation	roof:height (h1)	roof:height (h1)	roof:height	roof:height (h1)	roof:height (h1)	roof:height	roof:height	roof:height	roof:height (h1) and one of parameters: roof:angle (angle 1) or pitch:length (l1, can be used only if base has square form)
unnecessary parameters	-	-	gabled	one of parameters: highest_pitch:min_hight (h2) or highest_pitch:height (h3)	pitch:length (l1)	-	one of parameters: lowest_pitch:height (h2), highest_pitch:height (h3), lowest_pitch:length (l1), highest_pitch:length (l2)	one of parameters: lowest_pitch:height (h2) or highest_pitch:height (h3), one of parameters: lowest_pitch:length (l1) or highest_pitch:length (l2)	-	-	-	-
default values	roof:height=0	-	roof:orientation=along [long side of bbox]	roof:orientation=along, h2=0.5*h1	roof:orientation=along, angle 1 = angle 2 (redefines by pitch:length)	-	roof:orientation=along, lowest_pitch:height=roof:height*0.5 (redefines by one of parameters: lowest_pitch:height (h2), highest_pitch:height (h3), lowest_pitch:length (l1), highest_pitch:length (l2))	roof:orientation=along, angle 1 = angle 2, angle 3 = angle 4	-	-	roof:orientation=along	All roof faces of the building with the beginning in the same height, have the same inclination

Bridges

I've found, that some users tag bridges as buiding=yes or building=bridge to see bridge in Mapnik and other renderers, which work with buildings. I don't tell about buildings, which are used as bridges (tag building=bridge for them is correct) and don't tell about highways on bridges (we use bridge=yes for them). I think, that we should conform scheme of tagging bridges (in volume) to avoid such tagging for renderers. Normal buildings are tagged with building=yes (outline of building) and building:part=yes (part of building). Shoudn't we use bridge=outline for whole bridges and bridge:part=yes for parts of bridges? Dinamik (talk) 09:22, 4 October 2013 (UTC)

There is already a proposal about bridge/tunnel relation https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels Cmif4 (talk) 09:36, 4 October 2013 (UTC)

I knew about this proposal. But, as I think, it doesn't say anything about volume rendering of bridges. In terms of the proposal I can just tag an outline of bridge, but I can't write "height of the main parts of bridge above water is 9 meters, minimal height is 7 meters, here we have a pillar from 0 meters (from water) up to 15 meters". And other people can't - so they just write building=yes, what is incorrect. Dinamik (talk) 09:42, 4 October 2013 (UTC)

I see the problem that we currently only have 3D tags for buildings, so people map bridges (and other things e.g. from the man_made key) as buildings if they want 3D shapes. And I guess we have to think about what we want people to do in those cases.

However, bridges are perhaps one of the most problematic examples. Firstly, we would have to position roads and other features seamlessly on top of them. Afaik we do not have a solution yet for the analogous problem of parking facilities, paths, gardens etc. on rooftops. Furthermore, many bridges use complex shapes, e.g. arching tops, the cables of a suspension bridge and so on. And finally, I don't see how to properly integrate them into 3D terrain. It's hard enough to do with "normal" bridges. Because of all this, I'm inclined to first implement the existing bridge proposals properly - including various bridge types, multiple ways across the same bridge, integration in terrain, individually positioned piers and so on. Then we can look at what's still missing. --Tordanik 13:58, 5 October 2013 (UTC)

Using closed ways instead of multipolys for building:part members

The following problem in F4 WebGL is not encountered on buildings that use multipolygons for the building:part=*s, Kendzi seems to handle both equivalently.

• 

  Apartments Apartments - Rendering with F4 WebGL (view)

• 

  Apartments Apartments - Rendering in Kendzi plugin

--Cmuelle8 (talk) 00:45, 27 September 2013 (UTC)

The screenshot for F4Map was on a old cache version (building cache is updated every 24h), i checked it out and the building is now handled correctly like in Kendzi plug-in Cmif4 (talk) 15:07, 27 September 2013 (UTC)

Yes, this issue is closed, the cache expired and the building is rendered here as well. However, do you have a suggestion to better join the gable roofs in the middle - they meet in a 15-20 degree angle. Kendzi correctly cuts the roof at the joining line, but F4 continues to render the roof to the end of the rect. bbox it seems. Thanks for some light you may shed on this. --Cmuelle8 (talk) 18:48, 27 September 2013 (UTC)

I'm already aware that i need to improve the roof rendering on non rectangular polygons, for now it only fits to the minimal oriented bounding box Cmif4 (talk) 13:18, 1 October 2013 (UTC)

Building and building:part tags on one line

There are such sentences:

   Add an additional building:part=yes tag to the building=*.
   Note, that this method can be used only in case, when building (building=*) consists only from one part (building:part=*),
   because if building consists of two or more parts with different attributes (height=*, building:levels=* or others), we can't mark building outline as building:part,
   because such tagging means, that maximum height of building (the value, which is tagged at building outline) and other attributes of whole building refers to part of building (and it is incorrect).

But they does not make sense. If building (building=*) consists only from one part, we can't use building:part=* because... Because there are no contitions to use it! And if building consists from two or more parts, we should use second and third way from https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings#Building_parts I think that this paragraph must be deleted. What mean you?

P. S. Sorry for my bad english. --Edward17 (talk) 17:53, 1 October 2014 (UTC)

I agree that this method does not make sense and that list item could be removed. --Tordanik 20:55, 1 October 2014 (UTC)

These phrases were discussed earlier: "I saw, how editors added tag building:part=base to building=yes, because some renders didn't show volume of building, if building touch some building:part - so there were problems with rendering of indivisible buildings, which touched the buildings, cutted into parts", "I didn't want to say, that adding building:part=base to solve problems of some render is good idea, I just wanted to mark, that the only case, when building=yes and building:part=yes can be in one object, is when building consists from one building:part and building equals to this building:part". Also I see, that some editors think, that if, for example, building consists of part with 2 levels and part with 3 levels, it is possible to tag outline of building with building=yes + building:part=yes + building:levels=2 (and/or building:part:levels=2) and part with 3 levels with building:part=yes + building:levels=3 + building:min_level=2. I think, that some remark about it is useful. But I don't insist, that current version of text is the best. Could someone offer better version? I' like to have some place in wiki-documentation, to which I can direct users, who make mistakes, as I described before. Dinamik (talk) 09:45, 2 October 2014 (UTC)

Building (building=*) is one object, and building's part - second object. So they must be marked also in OSM as two different objects (lines or multipolygons). When some renders draws false image, it is render's problem, not data's problem. And one question: what render has this problem?--Edward17 (talk) 15:08, 2 October 2014 (UTC)

Nobody has given arguments that this method makes sence. So, can I remove this list item? --Edward17 (talk) 14:41, 27 October 2014 (UTC)

This incorrect rule was deleted from all <lg>:Simple_3D_Buildings pages. No problems have arisen, as I see. --Edward17 (talk) 14:39, 20 December 2014 (UTC)

Buildings with one side open

How do I map small buildings like these where one side is open? I tried adding a way to the side, where there should be no wall, tagged with building_part=yes + wall=no, but at least F4-Map is not recognizing that. Example: [5] and [6] Flaimo (talk) 20:58, 3 August 2015 (UTC)

Is there a building:wall anywher? You could add 4 buidling:part, one as the roof with min_level and 3 as walls. But I think the tag building=shelter should be used by the 3D rendere to do this themseleves or replace the building by a 3D-Model of a selter -karlos- (talk) 09:42, 14 May 2017 (UTC)

Dome starting from floor 0

I'd like to map a dome, but it's not a roof:dome. The entire building is a dome. How do I do that?

Did you counsider: height is including roof:height, roof:height is below height! Example: http://www.openstreetmap.org/way/222512591 -karlos- (talk) 09:35, 14 May 2017 (UTC)

So, for a 10 meter dom starting at ground, would this be fine?: height=10, roof:height=10 -- SwiftFast (talk) 11:20, 14 May 2017 (UTC)

Yes. Did you try it? What place/way-id is it? How do you do you edits; how do you check the result? You may use www.osmgo.org do see it after 5 minutes (overpass update time) -karlos- (talk)

Demo areas section

What do you think about moving the "Demo areas" section to its own page? It's repsonsible for a big part of the changes to the Simple 3D Buildings page, making it harder to keep an eye on and follow the history of changes to the actual specification. It also has grown quite large over time, and is no longer as necessary (with 3D not being nearly as rare in OSM as it was when the page was written). --Tordanik 14:09, 2 September 2017 (UTC)

Sounds good to me. I've started to templatize the table, which will cut down on the noise associated with adding new renderers or places to the table. (Apologies for the noise in the meantime.) – Minh Nguyễn (talk, contribs) 15:21, 2 September 2017 (UTC)

I split out Simple 3D buildings/Demo areas with the table. It's still transcluded in the main page, but at least you won't get notified about edits to the table unless you watch that separate page. – Minh Nguyễn (talk, contribs) 18:06, 22 September 2017 (UTC)

I agree. We should place a picture with some examples to click on to go to the extra demo page. I also would like to provide a map like this: http://osmgo.org/map/ -karlos- (talk) 16:25, 2 September 2017 (UTC)

That map seems useful and could be linked from the new page. :) I would prefer a text link over an image, though, if only to avoid problems like which 3D renderer to use for rendering that image. In fact, I think we should take down the File:Simple_3d_examples.jpg, too – it's not fair that OSM2World is the only renderer to get an image on this page (plus it's very outdated at this point). --Tordanik 17:19, 2 September 2017 (UTC)

Huesca is already in the demo areas, but Parque Tecnológico Walqa, near Huesca, should be added too, with buildings like Edificio I+D+i having great detail too: https://www.openstreetmap.org/way/216982276#map=16/42.1101/-0.4580 --Robot8A (talk) 11:20, 11 June 2018 (UTC)

Is there a timeline as to when Tordanik's proposal might be implemented? The "Demo areas" is a nice idea, but maybe better named, "Example 3D Cities" and another page, "Example 3D Buildings". The "Demo areas" are focused on overall cities, which can be impressive, but I think most new users who are interested in 3D will be looking for individual buildings. An "Example 3D Buildings" page could house a collection of simple, complex and extremely complex examples for users to learn from. --Chachafish (talk) 23:54, 9 February 2019 (UTC)

Hello, Following Tordanik’s suggestion of moving the “Demo areas” to another page, I’ve started the process and additionally added another page with links to 46 high-quality, individual 3D building examples in 14 nations. If you click on the new links, I think you’ll like what you see. “Demo areas” continues to display areas, whereas the individual 3D building page has more specific, focused material. I’m new to editing the wiki and I have no doubt that I’ve made mistakes here, but I know my work can easily be reverted. Apologies if I’ve stepped on any toes, but Tordanik’s suggestion is approximately 1.5 years old and I decided to make it happen. Thanks :) -- Chachafish

Misunderstanding regarding roof:height

Yesterday I added some tags to 3D render buildings. Today I checked on F4map and realized, that they obviously interpret "roof:height" as measured from the ground as opposedly to the OSM Wiki, where the roof height is defined as overall height - height of the façade. I wonder what to do now. Map for a proper appearance on F4map or according to the Wiki. --Rene78 (talk) 17:07, 8 November 2019 (UTC)

Assuming your observation is based on this building, and the current F4 map rendering is still using yesterday's data, I wouldn't come to this conclusion. You had the building tagged as height=9 + roof:height=8, which should produce a building that consists of 1 m high walls and a 8 m high roof on top. That's exactly what F4 map is producing. I suspect what you intend is actually height=17 + roof:height=8? (That is, the height tag should include the roof.) --Tordanik 19:51, 8 November 2019 (UTC)

Thanks Tordanik for the explanation. My stupid mistake. --Rene78 (talk) 10:30, 10 November 2019 (UTC)

building:part use

Paragraph "How to Map - Building parts"

"Ways tagged with building:part=* are mainly considered for 3D rendering. 2D renderers ignore the building attribute tags described in the following section."
Shouldn't it be called: Areas tagged with... ? --Chris2map (talk) 19:45, 19 January 2020 (UTC)

You're right, thanks for pointing this out! I've corrected it, as well as two other sentences which had the same issue. --Tordanik 19:48, 4 February 2020 (UTC)

building part outside outline

"The building parts can be located in any possible way (inside, outside, intersecting, touching) relative to the building outline in the presence of the type=building relation." - is there any valid use case of building:part outside building outline? Mateusz Konieczny (talk) 13:30, 28 May 2020 (UTC)

Well, i used it once at this building https://osmbuildings.org/?lat=47.82945&lon=13.05353&zoom=20.0&tilt=37&rotation=-174 for the middle part here https://www.openstreetmap.org/way/801962319 . Its basically two buildings, but with a connected roof. But i was told that building:part=* should not be used outside of the regular building, so i splitted it. So i think there are usecases where this should be possible. Negreheb 13:53, 28 May 2020 (UTC)

SketchOSM EOL

SketchOSM was a plugin for SketchUp that let you create 3D buildings parametrically for adding site context to your model. Buildings created with SketchOSM could then be shared with the world by publishing directly to OpenStreetMap (OSM). Per an update to their website, "SketchOSM is no longer available due to incompatibilities with newer versions of SketchUp. At this point, we are not sure if we are not sure if we will continue supporting it."

Are there any alternatives?

Any suggestions for editors affected by the EOL?

--Dónal (talk) 12:02, 28 August 2020 (UTC)

I'd say JOSM + Kendzi3D is still the best choice, even though Kendzi3D development unfortunately isn't that active at the moment. Alternatively, you could use JOSM alongside a standalone offline 3D renderer that can open .osm files saved in JOSM, such as OSM2World, although a separately installed program is of course far less convenient.

I've been thinking about offering a JOSM plugin based on OSM2World, alongside visual presets for roof shapes and such, to improve the 3D editing experience. It wouldn't be my first JOSM plugin and I could build on the work done by Kendzi, but I currently lack the spare time. --Tordanik 12:28, 28 August 2020 (UTC)

Instructions for tool developers

The text is the section Building outlines isn't clear for a tool developer. Should a building outline be never rendered if there are building parts? Or could there be cases when a part of the building outline should be rendered? More clarification is needed when and how to render a part of the building outline. --vvoovv (talk) 10:33, 25 January 2021 (UTC)

It depends on what given person want to achieve. Are you making such tool or is it a theorethical question? Mateusz Konieczny (talk) 11:14, 25 January 2021 (UTC)

I am a tool developer (OSM import for Blender) --vvoovv (talk) 11:32, 25 January 2021 (UTC)

I have rewritten this section to describe actually used tagging. Let me know if something is unclear. Note, if you want you may ask on tagging mailing list, global Discord server or other places listed in community index. Talk pages on wiki are quite low traffic and have low variety of people answering. Remember to mention that you are actually using OSM data and specific problem you have, at least for me I am more likely to spend time on such queries compared to theoretical discussions 11:56, 25 January 2021 (UTC)

Thank you the clarifications. Everything became more clear for now. --vvoovv (talk) 15:12, 25 January 2021 (UTC)

The rule that has been documented since 2013 is: The building outline is only rendered in 3D if the building has no building parts.

As this was only changed 4 days ago by this supposedly "minor" edit by George29, I've restored the previous long-standing documentation. --Tordanik 18:46, 25 January 2021 (UTC)

Based on mapping that I see, it seems that there are many buildings where only part of building area are redefined/overwritten by building:part=*. Is my impression wrong? Even if original proposal demanded something else it may make sense to mention that. And "the building outline is not considered for 3D rendering." is wishful thinking anyway, actual 3D renderers often act differently Mateusz Konieczny (talk) 19:05, 25 January 2021 (UTC)

I don't have any statistics at hand. But the examples I see of "overwriting" only part of the building are often wrong for more than just that reason. A typical issue is that people add the height for the missing building part to the building outline, resulting in an incorrect height for the building as a whole.

Yes, there are renderers that take the lazy way out and just render all building outlines all the time. This then leads mappers to map for that renderer by tagging the building's height as 0 or things like that, which in turn breaks other software.

S3DB exists exactly to avoid these incompatibilities between different renderers. S3DB was created as a tagging standard that tries to define a common agreement between mappers and developers of various renderers. It is not trying to describe everything found in the OSM database. Writing a working 3D renderer takes a lot of effort, and needs a stable data model as its foundation. This isn't like replacing amenity=foo with man_made=bar in a render style sheet. You can't rewrite fundamental assumptions of your software every time someone does a broken import and tries to change the wiki to match. --Tordanik 20:04, 25 January 2021 (UTC)

Tags for building outlines and parts is Confusing

I am having trouble understanding the example for utilizing the height and level tags for building modeling. The picture appears to break a single building into three different ones. But given the prior explanation of building:part=* I don't if the individually colored buildings sections count as individual buildings or as individual building parts. Could someone help me understand? Thanks! --IanVG (talk) 20:14, 26 July 2021 (UTC)