OSMBuilding icon indicating copy to clipboard operation
OSMBuilding copied to clipboard

"partIsInside" causes odd renderings. It is not "The part must be totally inside the building"

Open DerKarlos opened this issue 4 months ago • 7 comments

This Issue may relate or partly be the cause of #42

I tried your function partIsInside and had odd effects. It returns true if one of the points is inside or at the border of the shape. If neighbour parts share the same Node as the building, partIsInside will return true. (Check if ANY point in a part is within this building's outline.) But the OSM/F4map rule is: the part must be totally inside the building. I see this Wiki definition: "2D footprints can (and often need to) overlap" only for parts, not for overlapping the outer/building footprint.

But that may not apply vor building:part=balcony

You may invert it’s logic:

partIsInside(part) {
    const shape = part.shape;
    for (const vector of shape.extractPoints().shape) {
      if (!BuildingShapeUtils.surrounds(this.outerElement.shape, [vector.x, vector.y])) {
        return false;
      }
    }
    return true;
  }

There are two examples: 440257472 and 440257471 They are even more crazy. The neighbour parts get visible, but the building it selves not.

I changed my copy of your code and it looks good - mostly: Way 316556318 includes a roof-relation 4166727, but our "surrounds" calculates Node 37 outside. Hard to tell why. A drawing may help, made by "surrounds".

DerKarlos avatar Aug 05 '25 16:08 DerKarlos

Can you please provide a source for the “OSM/F4map rule”? In my research of OSM rules, the only guidance is that a “building outline must be completely filled with parts” if any parts are defined.

Beakerboy avatar Aug 05 '25 17:08 Beakerboy

https://wiki.openstreetmap.org/wiki/Key:building:part is only about a part, not the relation to buildings. (I mentioned balcony) https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings: ".. simply position all building parts inside the building outline. Relation could be useful in the case where at least one part of a building is hanging over the building footprint ..." I read this as: Your "partIsInside" should do this too, except for: relations part gets rendered anyway. I did not test it with F4 yet.

As F4map is closed source, you only can try it. I did and even if a part is only partial outside the building, it disappears. A, I found this: "building:part not fully included in a building are ignored." here: https://wiki.f4map.com/render

The "completely filled with parts” is a related but different topic and also often not done by the users! Example: https://www.openstreetmap.org/way/107643543 Tornarik removes the building if parts cover 60% of it. The example is 65% and we do not have a final solution yet. My idea goes about this way: if the relation has tagging for roof, it should stay.

DerKarlos avatar Aug 05 '25 17:08 DerKarlos

So F4Map is by no means a standard, and it in fact goes against a few standards if I remember correctly.

As far as your specific examples go:

440257472 Has no parts, so the outer border should be used to render the building. However, the neighboring building that shares walls with 440257472 has parts, and those parts happen to fall within the “bounding box” of 440257472. My plan for excluding these is to check if the center of a part is within the border for cases where points on the part are not inside the border, but lie on the border.

Your suggested change to the function will break the many cases where a single point of a part is not exactly on the border, but outside it by the tiniest amount.

Beakerboy avatar Aug 05 '25 17:08 Beakerboy

I will continue the interesting topic F4Map!=OSM in the forum. Also the "60% coverage".

I am happy, we agree about when a part should be visible.

I see the "tiniest amount" problem. Firstly, the Ways should use the same Nodes! But as a backup, the function "includes" could have a hysteresis added in the code. Done this, your complicating backup "center of a part is within the border" is not needed. But we don't need to agree about all strategic details.

It's not important, just interesting: why is 440257472 not visible?

DerKarlos avatar Aug 06 '25 07:08 DerKarlos

Who or what is Tornarik? What do you mean by “hysteresis added in the code.“

My project is meant to help users create a “properly rendered building” and if it has any parts, those parts are supposed to fill the outline, so I do not render the outline. Doing so would encourage people to not fill in the building the way they are supposed to.

Beakerboy avatar Aug 06 '25 10:08 Beakerboy

Oh, Tordanik is the maintainer of OSM2World, the most detailed 3D Rendere, limited to DACH only (German speaking countries)

A hysteresis is an accepted tolerance. If the Node is outside the building but within the hysteresis value, it counts as inside. This would solve this issue.

If one inspects an existing building, edited for the F4map renderer, it will look "wrong". (I need to backward analyse, how the F4Map logic is) You could check the part coverage. You could offer a key to make the building visible.

Well, we don't need to agree.

DerKarlos avatar Aug 06 '25 12:08 DerKarlos

The way the site is supposed to work is if you append &info at the end of the url, you are offered some more information and control over the rendering. One of the controls is the presence of a visibility selector. The outer building should be able to be toggled on and off, however there is currently a bug that prevents it from working.

Beakerboy avatar Aug 07 '25 03:08 Beakerboy