Talk:Simple 3D Buildings

* For discussion content from the period 2012 to the end of 2019, please see the archive.

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)

Orientation of a roof:shape=side_* with roof:direction

One thing what should be clarified is the rendering of roof:shape=side_* roofs since they AFAIK were never defined in S3DB and came in naturally to deal with. Normally, roof:direction is defined to be in the direction of the slope / quadrilateral areas (best seen on roof:shape=gabled). However, I currently tag half-roofs with the wall facing away from the direction similar to roof:shape=skillion because such roofs are asymmetric and it's easier to make the roof point away from the wall than if the wall lies parallel to roof:direction but it also means that renderers will render such roofs rotated by 90° because their full equivalents do expect a different orientation.

I also wonder if it makes sense to combine both roof:direction with roof:orientation to denote how a roof has been halved. For example, it's very common for porches / entrances to be a hipped roof, albeit halved at the triangular sides rather than the trapezoids like the current definition of roof:shape=side_hipped, especially because roof:orientation is otherwise useless with such roofs thanks to their assymmetricity. —Preceding unsigned comment added by ManuelB701 (talk • contribs) 10:21, 2 September 2025 (UTC)

Definitely those side_* roofs are NOT the part of S3DB standard. It's rather a part of OSM-4D. However, usage of roof:direction tag is well-defined for them there.

, , ,

Zkir (talk) 20:27, 3 September 2025 (UTC)

This talk page needs cleanup of old discussions

There are a lot of duscussion topics from over 10 years ago, with no updates or resolutions . This makes the page very hard to read and some kind of archiving or cleanup is needed to make sense again . Jbohmdk (talk) 13:04, 31 May 2026 (UTC)

IMHO a good idea! I've archived the content till end of 2019 to Talk:Simple 3D Buildings/Archive 1. --Chris2map (talk) 14:14, 31 May 2026 (UTC)

One may cleanup the discussion, but Simple_3D_Buildings is some kind of memorial page. It contains results of discussion which took place 14 years ago.

In my opinion the best option is to leave both the article and discussion in peace, and start discussing Simple 3D Buildings 2.0, provided there are enough volunteers (which I doubt, really). Zkir (talk) 19:40, 31 May 2026 (UTC)

I see your point. My action was certainly a bit hasty, but was by no means intended to be disrespectful to the work. I wonder what is the better way to keep the history — whether it might be better preserved as an archive — or whether it should be reset and new pages started. If so, however, the existing content should ideally be designated as historical or immutable. Yet I find this problematic as well, given that the schema is still currently in use — or could be. Where, then, would discussions regarding its current usage take place? Chris2map (talk) 20:13, 31 May 2026 (UTC)

"If so, however, the existing content should ideally be designated as historical or immutable" - -Yep.

"Where, then, would discussions regarding its current usage take place?" -- Mostly on the community forum, with #3d tag: https://community.openstreetmap.org/tag/3d Most relevant thread is IMHO this one: https://community.openstreetmap.org/t/default-values-vor-3d-rendering-and-2d/142110/20

However, it depends on what exactly you would like to achieve: to create a new page with overview of the current state of 3D in OSM, similar to 3D development or 3D tagging, both godlessly outdated and worth cleanup, or just ask questions (most of them without any answer, because SM3D is immutable)

best regards, Zkir. Zkir (talk) 14:12, 1 June 2026 (UTC)

Document complex syntax as currently accepted

As the linked page for "complex" or "full 3D" is essentially dead (lots of outdated talk and a meaningless link to indoor-only syntax), either add the living syntax to this page or create a new page for the currently implemented syntax throughout the OSM project . As a mapper my interest is to map complex buildings in my neighborhood that have all manner of difficult elements like internal ways and parking areas nested in weird ways, building outer walls differing by level etc. etc . As I map mostly by eyesight I don't have exact elevations in meters for relevant levels with no indoor GPS reception, so specifying that A is on top of B without knowing how many meters from the curb height to the platform level is highly impractical . The place giving me the most trouble in recent years is the Herlev Bymidte shopping mall (polygon 43544973 and connected structures on all sides) and there are entire buildings on top that aren't even mapped because figuring out the right notation is difficult . Jbohmdk (talk) 13:21, 31 May 2026 (UTC)

What syntax do you have in mind? What tagging scheme do we have beyond S3DB? Zkir (talk) 16:51, 1 June 2026 (UTC)