Render building:part

[wolfv]

building:part is a tag used to annotate the 3D structure of buildings.

It would be great to render it in 2D as well, to highlight distinguishing 3D features of buildings.

E.g. I mapped this building:

Which actually has two different heights and an overlap.

I propose to render the different height extrusion outline with a lighter shade than the building outline and the overhang maybe with a lighter background color, ie (quick sketch in inkscape):

I guess it would require to add some logic to the renderer to correctly recognize the 3d shapes etc.

[wolfv]

Building can be seen in 3D here: http://demo.f4map.com/#lat=47.3713141&lon=8.5319920&zoom=19&camera.theta=32.699&camera.phi=-54.431

[HolgerJeromin]

Rendering building:min_level>0 (overhang) with a light color is a nice idea. A very light outline for building:part could work, too. But probably both things are out of the scope of this project.

[HolgerJeromin]

Right now many complex building parts are mapped as buildings to show the structure.

[kocio-pl]

It would look like this building for example (however it needs to be fixed, since now it's mistagged as separate buildings, as @HolgerJeromin has just said), so only boundaries of building:parts, but no opacity, since @gravitystorm don't want it.

[wolfv]

I would guess that two rules could suffice, and it could be pretty easy to implement:

Draw building part the same as building if min_level 0 or not set.

Draw building part with lighter background if min_level bigger than 0.

I don't know how layers work in carto css but drawing would need to be ordered after max_level I think. Also the building footprint would be drawn first.

[HolgerJeromin]

Thanks for the example kocio-pl.

[HolgerJeromin]

Draw building part the same as building if min_level 0 or not set.

Is not even needed. As the main building is already painted below .

[dieterdreist]

sent from a phone

Am 20.09.2015 um 14:21 schrieb Wolf Vollprecht notifications@github.com:

I would guess that two rules could suffice, and it could be pretty easy to implement:

Draw building part the same as building if min_level 0 or not set.

Draw building part with lighter background if min_level bigger than 0.

I would draw first the building fill, then the building part outline, than a building outline. No fill for the building part.

Labeling would also be nice.

[mboeringa]

I think this request actually hits on a much more fundamental question:

_Do we want to represent a pseudo-3D map, or a proper and well designed 2D map?_

Personally, I think the current rendering, that already incorporates "pseudo-3D" properties like overlapping underground and aboveground structures, falls short... In many cases, the jumble of overlapping polygons leads to an incomprehensible map. A rather infamous example, that has been cited in multiple issues here in the issue tracker, is Berlin Hauptbahnhof:

http://www.openstreetmap.org/node/240109189#map=17/52.52493/13.36985

I also think the technical challenges to realize a good pseudo-3D map, that would need to include the layered rendering of highway areas as well as building(:part)(s) to make sense, is far bigger than most of you realize. It has big consequences for an essentially 2D rendering tool chain.

I realize this is a subjective personal opinion, but I think that carto should focus on the 2D aspect, and leave "3D" to true 3D rendering tool chains and websites like F4Map, OSM2WORLD or OSMBuildings, that already show pretty impressive results in displaying true 3D renderings of OSM data. The value of pseudo-3D over 2D is far less than these true 3D renderings IMO.

[dieterdreist]

sent from a phone

Am 25.09.2015 um 09:42 schrieb mboeringa notifications@github.com:

I think this request actually hits on a much more fundamental question:

Do we want to represent a pseudo-3D map, or a proper and well designed 2D map?

I disagree, the building:part tag is not a pure 3D thing, it is used in 2D mapping as well. For rendering, some typologies (e.g. bell tower of a church, chapel of a church, choir of a church, etc.) might be interesting and of course the names of these parts for labeling. Current map still has a lot of building parts mapped as proper buildings to have the names displayed, by rendering a name for the part we could incentivize better mapping.

[kocio-pl]

@dieterdreist +1 Building:part is a part of a S3DB scheme, but it doesn't mean it is tied only to 3D - building can have different parts and seeing them helps recognize the overall shape.

[wolfv]

I can see where you are coming from, @mboeringa, but I would argue that this might be solved by introducing a tag like "render_2d=yes" (I know, you shouldn't tag for the renderer) but heuristics might have a hard time to decide if that building structure should be rendered in 2D or not.

E.g. this building might be "overwhelming" in 2D:

[dieterdreist]

sent from a phone

Am 25.09.2015 um 10:20 schrieb Wolf Vollprecht notifications@github.com:

E.g. this building might be "overwhelming" in 2D:

maybe building:part definition allows for such splitting into tiny parts, but then it's clearly not mapping different building parts in a typological sense when you split a cupola into infinitesimal parts to account for the round shape (onion). Surely those won't have individual names whose labels would clutter the rendering and those interpolations should have a value we could exclude from rendering outlines (if mapping them as building:part and not with some dedicated 3D tag is generally accepted practice).

[kocio-pl]

Where is this building? We should test the rendering of something like this: the whole thing is to export data to the *.osm file and simply replace all the building:part= with building=.

[wolfv]

Moscow, red square (I agree upon inspection it would be more correct to tag it with roof:shape=onion)

http://demo.f4map.com/#lat=55.7526954&lon=37.6229353&zoom=20

[mboeringa]

I can see where you are coming from, @mboeringa, but I would argue that this might be solved by introducing a tag like "render_2d=yes" (I know, you shouldn't tag for the renderer) but heuristics might have a hard time to decide if that building structure should be rendered in 2D or not.

The Simple3D buildings tagging scheme already has a solution for this: each Simple3D building should in fact have a single closed way or multipolygon associated with it representing its 2D ground level outline. This way or multipolygon should be tagged with role=outline as part of a relation tagged with type=building.

Unfortunately, many people adding 3D building fail to create both type=building relations and the proper 2D outlines with appropriate role. See here for more info:

http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

[kocio-pl]

That's most probably Saint Basil's Cathedral. Well, even if I was not sure, now I'd say "go for it!" even with such an extreme example:

It just subtly adds value (more shape info) without making the image overloaded. Also compare it with a 1st floor plan on Wikimedia Commons.

The only difference between this fast test and planned (outlines-only) rendering is that now the whole building is light brown, because I would have to add POW tags everywhere. However other buildings near Red Square would look exactly like this:

[mboeringa]

Although this doesn't look bad, I think there are more questions to be answered before jumping to conclusions:

• What is the consequence of adding highly detailed building models to the _render_ database of OSM as a whole in terms of render performance and database maintenance. As can be seen from this particular example, adding building:part for all buildings, could potentially increase the size of the polygon table in the render database by an order of a magnitude. You have to realize that many of the current building:parts only reside in the non-PostGIS _edit_ database. The render database has to deal with other challenges. I sure would like to see input of @pnorman or @gravitystorm on this one.
• At what scales is this appropriate? Does this still work zoomed out, and if not, where to put the cut-off?
• Does this also work for buildings with intricately mapped, and currently displayed, indoor pedestrian areas (probably partly bad tagging, but there are many), I am especially thinking of the many railway stations and terminals that have many pedestrian paths mapped (often highway=footway or highway=steps) and currently visible.

[kocio-pl]

Sure, it was just a quick test, but I can also test rendering other examples if you give me some. Of course technical questions are perfectly valid and worth further analyzing.

[HolgerJeromin]

Iirc after using hstore after db reload the information is in the database. If we use it or not, is a sql/mapnik performance question but no db size question.

[mboeringa]

Iirc after using hstore after db reload the information is in the database

I have my doubts if this is true. osm2pgsql needs to generate geometries of these building:parts and the tagging involved, and unless it already does so, the geometries are probably not in the database, nor will they be after adding hstore. hstore just adds full tagging info associated with existing geometries in the database.

The good thing about the F4Map, OSM2WORLD, and OSMBuilding concept of "rendering client-side" of 3D objects, versus Mapnik pre-rendering server-side, is that they do not have to worry about render performance bottle necks on the server side, like with carto. If they can shuffle and send the 3D building data in its most basic form to the client, the client is left with the task of dealing with the work of the rendering itself.

[mboeringa]

I have my doubts if this is true. osm2pgsql needs to generate geometries of these building:parts and the tagging involved, and unless it already does so, the geometries are probably not in the database

Thinking about it a bit more, I may need to correct myself here. Geometries for building:part may indeed already be in the database, it all depends on how osm2pgsql processes the data (I am not to familiar with the details here as I don't have it running).

If they are, hstore should allow selecting them when added like @HolgerJeromin suggested.

[matthijsmelissen]

I think building:part is a too specific part for the general repository, adding a lot of noise to the map, and I'd prefer not to render it.

[kocio-pl]

Even if it makes noise for you, I feel building:part is a general object - I can think of no thematic map that would enclose it. It's just showing more details about general thing, not special types for special audience or something like that.

[pnorman]

I'm skeptical about building:part, and also think it adds too much noise.

[dieterdreist]

sent from a phone

Am 19.10.2015 um 21:38 schrieb Paul Norman notifications@github.com:

I'm skeptical about building:part, and also think it adds too much noise.

referring to labels, outlines, fills or any of them?

cheers, Martin

[pnorman]

referring to labels, outlines, fills or any of them?

Mainly the outlines. I suspect any attempt to use fills in place of outlines would run into the same problems. Labels, I have no opinion on one way or the other.

[dieterdreist]

Am 20.10.2015 um 09:03 schrieb Paul Norman notifications@github.com:

Mainly the outlines. I suspect any attempt to use fills in place of outlines would run into the same problems

I agree that outlines will raise the noise level, at least for most zooms, 19 would likely be ok, maybe also 18, when the line density becomes relatively low.

Fills might come into play for specific parts, similar to how specific building types are highlighted (e.g. more significant parts like towers or cupolas could be slightly darker)

[pnorman]

We're not a 3d/2.5d map, which is what you need for a reasonable rendering of building parts. Drawing lines in the middle of the building wouldn't make it clear which part is higher than others, and transparency is not an option.

[zlant]

Рисование линий в середине здания не было понятно, какая часть больше, чем другим, и прозрачность-это не вариант.

But it is clear that the building has a separate part

[dieterdreist]

here are more examples where the building:parts in 2D representation add a lot of structure. This is not about 3D (rather we should exclude those objects that are only useful in 3D).

[mboeringa]

here are more examples where the building:parts in 2D representation add a lot of structure.

That structure though, is only of limited use. It even may falsely suggest "indoor" tagging features, like rooms, walls, and corridors, that in reality likely have no bearing at all to how the feature is mapped in terms of building:part objects. A building:part object is just an arbitrary 3D volume, often chosen for the easiest way to construct the entire building from multiple "building blocks" (the building:part objects), with no or little relation to internal structure of the building.

[dieterdreist]

2018-02-14 19:22 GMT+01:00 mboeringa notifications@github.com:

here are more examples where the building:parts in 2D representation add a lot of structure.

That structure though, is only of limited use. It even may falsely suggest "indoor" tagging features, like rooms, walls, and corridors, that in reality likely have no bearing at all to how the feature is mapped in terms of building:part objects. A building:part object is just an arbitrary 3D volume, often chosen for the easiest way to construct the entire building from multiple "building blocks" (the building:part objects), with no or little relation to internal structure of the building.

I would see the case you describe an exception, usually there will be a clear relation between building parts and the inner workings and volumes. In traditional buildings this is generally the case.

[mboeringa]

I would see the case you describe an exception

May I remind you of this image posted above (and many other examples in the vicinity of it):

Saint Basil's Cathedral in Moscow

Even in the simpler example of Berlin cathedral you selected yourself - that I happen to have upgraded from a more crude example two years ago or so - the building:part objects have little bearing to the internal structure.

Anyway, I just wanted to point out with my remarks that "structure" is probably not the best reason to start showing building:part objects. Whether there are other convincing reasons is another matter.