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 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)

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)

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)

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)

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)

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)