3D OSM buildings within buildings not rendering properly

[hardreddata]

Consider the Queen Victoria Building in Sydney, Australia

I was inspired to contribute to OSM by adding some new attributes (domes, colour) to this building. These are not yet reflected in the Cesium data set.

In OSM the various domes are given their own "building" which sits inside the larger building.

See story which has missing building between cylinders representative of domes https://cesium.com/ion/stories/viewer/?id=ecca852d-d926-4404-a5f8-1e4ad0e5b5e2

See also screenshot from OSM Buildings:

https://demo.f4map.com/ also renders properly.

For reference, Cesium 1.68 in TerriaJS is also missing the central building.

This is an Ion ticket as I am not using Cesium directly.

I mean well. This is an amazing development for Cesium and I intend to encourage my colleagues to participate in improving the OSM data during any spare time they may have.

[kring]

Thank you @RussellGrew, this kind of report is very helpful and I will take a look.

[kring]

The quick (but possibly incomplete) answer here is that the main part of the building is missing because way:40717424 is not marked as a building:part. Simple 3D Buildings says:

When a building has any building:part=* areas, the building outline is not considered for 3D rendering.

The way contains a bunch of parts, so it is considered an outline and is not rendered. By adding a building:part tag to it, the outline will also be its own part, and so it will show up.

Now the next question is, why do OSM Buildings and F4Map display it? Well, I'm not completely sure. They seem to be using a different heuristic for deciding when to include the outline in a building that also has parts. We can almost certainly tweak our logic. This is a tricky thing, though. The danger is that we end up showing the outline when we shouldn't, and it obscures or depth fights with the parts. And when that happens, it's harder to fix. As compared to the present situation where, when we find an outline missing, the solution described above is a straightforward change to the OSM data to bring it more in line with documented OSM best practices, and it is unlikely to break any existing clients.

I'll think more about this, but in the meantime I think adding building:part: yes to the QVB building will be a good change.

[hardreddata]

Thanks for the prompt response.

I realised the story link may look correct in time. I include a screenshot for the record.

I agree the code should be written to specification if at all possible. Otherwise anarchy.

I have made the suggested change to the QVB. Though I wonder if https://wiki.openstreetmap.org/wiki/Key:building:part is in strict agreement with https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

I think I read monthly updates to this data set in Cesium? Do you have a date in mind for the next one? Such that I can circle back and check it.

Looking at Sydney there are some other rogue data examples in

Though these likely include a different artefact. Presumably which height estimate to use. The Sydney tower is arguably at half mast compared to some sources. That BNP Paribas Centre is a (stubby) monster. Perhaps this is another ticket.

I had a bit of a look globally and cannot readily identify similar issues to the QVB one. It will be interesting to see if others make similar observations. I hope they don't!

I am happy if you want to close this.

[kring]

Though I wonder if https://wiki.openstreetmap.org/wiki/Key:building:part is in strict agreement with https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

Well, I'd say the Key:building:parts page isn't even in strict agreement with itself. 😆 It implies that the building way is part of the building with phrasing like "Note that building:part=* are optional areas used in addition to a building=* area" (emphasis mine). However, it also says that the main building outline should completely contain (both horizontally and vertically) all of its parts. If we follow that rule, there's truly no point in adding parts because they'll all be hidden inside the outline. Long story short, I think we have to side with https://wiki.openstreetmap.org/wiki/Simple_3D_buildings on this one.

It may be slightly more correct to add a new part which is the main body of the QVB building, and then modify the existing outline way to include the full range of heights of all the parts. But it's certainly common practice to just add the building:part tag, as you've done.

The problem with the BNP Paribas Centre is fixed already. We were ignoring building:levels because the proper tag is levels. building:levels is common though, so now we support that too.

Something is definitely wrong with Sydney Tower. The yellow observation deck is supposed to start at 240m and go up to 270m according to the OSM data, but instead it starts (according to the measure tool) at ~194m. I think what may be happening is that the height is not being adjusted properly for terrain because it is a completely independent part from the main tower, and that part does not touch the ground. I'll have to think about how we can be smarter here.

Sticking to monthly updates, the next one will be 1 July or so.

[hardreddata]

Hi @kring,

I love your work and am taking a tour of regional centres.

Somewhat on topic (well meaning observations), do you note anything obvious I can do to fix the roof of the below? It doesn't track with the building underneath it. The OSM website editor seems to present a tidier list of tags than those available to you. Is the renderer perhaps confused? Or is this a bug?

Slide 2 of the same story as before https://cesium.com/ion/stories/viewer/?id=ecca852d-d926-4404-a5f8-1e4ad0e5b5e2

On this occasion Cesium does a better job than OSM Buildings with the adjacent structure which used to be the train station.

See also https://osmbuildings.org/?lat=-32.92664&lon=151.78497&zoom=19.0&tilt=28&rotation=-4

I have edited the trendy university building and City Hall further along the map based on your advice. I gather Cesium won't change colour based on a material tag and relies on a strict colour instruction.

I nearly took this to the community. Please do let me know if you would prefer I did as the scope of this ticket is creeping.

Cheers.

[kring]

Thanks @RussellGrew! :)

That's a known limitation of the hipped roof type right now - it always fills the bounding rectangle rather than conforming to the shape of the polygon underneath. The gabled roof type does this correctly; I need to apply that algorithm to the slightly more complicated hipped roof shape.

We do turn some materials into colors. Here's the list:

Material	Color
concrete	#C0C0C0
glass	#7A96A5
metal	#C0C0C0
grass	#006400
brick	#640000
stainless_steel	#C0C0C0
copper	#B87333

I don't think a lot of thought went into these.. 😬
It's easy to add others and to tweak the mapping.

[hardreddata]

Thanks for clarifying. I feel your pain with the colours. The copper QVB domes can in reality be so many colours. I stuck to the web colours to try and narrow scope. Am I able to explore this locally by downloading OSM data and using CesiumJS? Such that I can examine and refine my crude edits. Or the implementation is tied to Ion?

…

On Tue., 23 Jun. 2020, 8:09 pm Kevin Ring, ***@***.***> wrote: Thanks @RussellGrew <https://github.com/RussellGrew>! :) That's a known limitation of the hipped roof type right now - it always fills the bounding rectangle rather than conforming to the shape of the polygon underneath. The gabled roof type does this correctly; I need to apply that algorithm to the slightly more complicated hipped roof shape. We do turn some materials into colors. Here's the list: Material Color concrete #C0C0C0 glass #7A96A5 metal #C0C0C0 grass #006400 brick #640000 stainless_steel #C0C0C0 copper #B87333 I don't think a *lot* of thought went into these.. 😬 It's easy to add others and to tweak the mapping. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKEPO2V4OTG7EXIKF2MMMK3RYB5N5ANCNFSM4N5IPINA> .

[kring]

I stuck to the web colours to try and narrow scope

Yeah any named CSS color should work. All colors are exactly as defined in CSS except these:

Color Name	Color Value
brown	#964B00
red	#640000
green	#006400
black	#4C4C4C

Am I able to explore this locally by downloading OSM data and using CesiumJS?

Unfortunately there's no way to try it yourself currently. We're considering adding a feature to ion where you can upload your own (non-global) OSM data and it will create 3D Tiles of it for you. The main motivation for this is so that users can put the OSM Buildings on their own custom terrain, but it'll be good for trying out edits, too.

[kring]

@RussellGrew I've fixed some things and regenerated Cesium OSM Buildings for Australia only. Here's the story (this story link won't work long term): https://cesium.com/ion/stories/viewer/?id=1e636aef-8d44-4a06-8436-d2f32524fcd0

If everything looks good, I'll get the whole world updated with these changes in the next few days.

One thing I noticed is that BNP Paribas Centre is floating. Looks like another case where the base, https://www.openstreetmap.org/way/335699134, is not tagged as a part so it's being excluded.

[hardreddata]

Initially we had this ridiculously cool 3D globe that ran on a very small fraction of computers from your recent podcast interview made me laugh. Put that on a t-shirt in years to come.

Thanks for the opportunity to review. I may have overstated my tour of regional centres.

I see you solved the Sydney Tower.

One Bligh was set to GhostWhite which may or may not be rendering in the chosen colour. I have since changed it to LightSkyBlue out of curiousity. https://www.openstreetmap.org/way/335687876

I added the part flag to BNP Paribas Centre. Thanks for picking that up. I have also done the same with Central Station for https://www.openstreetmap.org/way/16748116 ~ last I walked past the area the clock tower was not floating.

The domed roofs are generally squatter than I was expecting.

Great progress. I think good to go.

[kring]

Put that on a t-shirt in years to come.

😆

I see you solved the Sydney Tower.

Yeah it was essentially the same problem as BNP Paribas Centre. The observation deck at the top is not actually part of the building, it's a separate building (at the OSM data level) that happens to be in the right place. But because that separate building isn't touching the ground, the OSM tiler wasn't adjusting it for terrain. Now it does, but only based on the terrain height at the center. So there's still potential for vertical misalignment, but it should be much closer. The best fix is to create a building relation that pulls all the parts together into one logical building, and then the tiler will keep them all together when it adjusts height.

The domed roofs are generally squatter than I was expecting.

This is controlled by the roof:height tag:
https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Roof

Note that the roof height comes out of the total building height.

Thanks for trying it out!

[hardreddata]

I mentioned this topic in https://www.openstreetmap.org/changeset/87370508 where the motivation of my recent building:part edits has been questioned.

[kring]

Ok cool, happy to hear other suggestions for how things should work. As I mentioned before, adding a "new" part for the base, rather than re-using the outline as the base, may be slightly more correct. I do believe it's common practice to make the outline double as a part when that works, though.

[andrewharvey]

Is this the same issue as why https://www.openstreetmap.org/way/466884765 isn't showing up

As far as I can tell it's correctly tagged as a building=apartments since it has it's own name, address, entrance, but is still part of another larger building area which it intersects. So I think the OSM tagging is correct, but interested to hear why it's not showing up.

[kring]

Hi @andrewharvey, thanks for dropping in! Yes that's the same issue. way:466884765 contains way:444590104, and the latter is tagged building:part. Therefore we treat the former as an outline containing parts and do not render it.

[kring]

What's the larger building area you mentioned, though? way:466884765 doesn't appear to contained inside any other ways or relations that I can see. Even if it was, because it's only tagged building and not building:part, it still wouldn't show up.

We're following this rule from https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Building_outlines:

When a building has any building:part=* areas, the building outline is not considered for 3D rendering.

There's no explicit tagging for outlines. Any building that spatially contains one or more parts is considered an outline.

[andrewharvey]

Hi @andrewharvey, thanks for dropping in! Yes that's the same issue. way:466884765 contains way:444590104, and the latter is tagged building:part. Therefore we treat the former as an outline containing parts and do not render it.

Thank you for looking into it. https://www.openstreetmap.org/way/444590104 is a part of the building at https://www.openstreetmap.org/way/205137165, it's not a part of the building at https://www.openstreetmap.org/way/466884765.

Even though they overlap I'd still consider them two different buildings. They aren't internally connected have different address/name, entrances number of floors, different use.

[kring]

Ok, that makes sense. How can we determine that from the data, though?

[andrewharvey]

Ok, that makes sense. How can we determine that from the data, though?

I guess on the data side I should use a building relation https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Building_relations to specify which building:parts are part of which building for these more complex scenarios.

I totally understand now why you'd also need to exclude the building way when there is a building:part inside (I couldn't see why before, but can now).

[kring]

Yeah that seems like a good use of a building relation to me. Thanks for checking my reasoning on the building/building:part stuff.

[Matthias84]

I have to confirm this issue with composed buildings. See this example at the city of Rostock, where the buildings in front are corrupted and the church in background as well.

Please consiider following the best practises of other existing 3d OSM renderers, otherwise users might start to change osm tags to fit your requirements, but create broken vis on other software.
OSM is always about dealing with imperfect data. Here it's esp. not to rely on the relation and render also the full building outline, if it's not completely covered by other building:parts.

[kring]

@Matthias84 we don't require a relation, but we do follow the advice in https://wiki.openstreetmap.org/wiki/Simple_3D_buildings that says:

When a building has any building:part=* areas, the building outline is not considered for 3D rendering.

If we were to do as you suggest and render the outline unless it is completely covered by parts, it would definitely break other buildings in OSM. There may be a more subtle rule we could follow that would fix the buildings you've shown here (which according to my best understanding are modeled incorrectly) and avoid breaking others (which are modeled correctly), but it's unclear to me what that rule might be.

I completely agree that we don't want people to start changing OSM tags to fit our requirements. However, in this case, if the buildings you've shown are changed to follow the authoritative OSM advice for tagging 3D buildings that I linked above, they will render correctly in Cesium. That is a correct and reasonable thing to do even if other renderers don't require it. Specifically, you need to add building:part: yes to any ways that contain parts and yet should be rendered in 3D.

[Matthias84]

Well I see your point, but on the other side a lot of other 3D OSM renderer work fine in dealing with this data, without creating corrupted visual objects?
Could you please checkout how other renderers interpret the schema and mimic the object creation?