Please do not apply access=private to paths unless they are truly confirmed off-limits to the general public. This tag implies forbidden access under _all_ circumstances and forbids routing. Thank you!

Re helipad roof or not: I admit the semantics are a bit unclear, but if that particular structure doesn't qualify as "a roof", then I couldn't imagine why we do have "building[:part]=roof" at all.

I would say something is a roof IFF it doesn't contain an interior volume, which is the case here.

The fact that there is a helipad (mapped as aeroway=helipad) on that roof is unrelated. It is kind of unique that a building=roof is built solely for the purpose of being walkable, but I think that's the case here.

Re fractional leves: I've seen that done in some other places and it does render correctly on F4Map and Streets.GL iirc. Heights are definitely better, since they are unambiguous, but I don't see anyting wrong with fractional levels. In the code it probably just multiplies that number with some fixed "assumed story height", so it doesn't matter whether it's fractional or not.

Thank you for clarifying on your previous CS. May I still suggest that the structure be indicated "building:part=roof" rather than "=yes" and heights be given in term of building levels - as it is the case with the rest of the building?

Actually, the stories of the building are of different height, so it would be most precise to work with heights here! But I think the whole building should be indicated *either* in terms of eight *or* in terms of levels - mixing the two will inevitably lead to problems. If we have the rest of the building in terms of levels, then so should be the helipad.

Why did you change roof to yes on osm.org/way/1218757854 ?

This is, in fact, a (walkable) roof (w/ helipad). Also, are the given heights correct? If so, I think they should be added accordingly on the main building parts such that the roof/helipad is actually above. Currently, the helipad intersects with the building on f4map.

Depends on whether it could be fixed ;) It should be obsolete now, at least for the time being.

No, there musn't be a point of contact between the mentioned polygons. They are geometrically entirely unrelated; snapping them both to a common point would represent a completely wrong topology.

I will improve the current "makeshift" outline and snap it to the points elsewhere, where vertices already exist. On the mentioned intersection, it will have to remain approximate.

I will correct the helipad. You are right, although it's "only a roof", it's reasonable to demand that the "non-existing" building-body not intersect with the rest of the building.

I'm not aware of any problem with the helipad "building:part=roof" structure. What are you referring to?

Yes, I'm trying to work out a satisfactory solution and I'm aware of the current breakage.

Concerning the "outline", the following constraints are problematic to reconcile:

a.) F4Map interprets "Simple 3D Buildings" (S3B) such that it requires that all building parts are within the "outline" of the building. Previous attempts (which mapnik would render) where the "outline" did not encompass all members caused parts to be missing in F4Map
b.) As you say, the "outline" should reasonably be the projection of the entire building and all its parts (the footprint) (congruent with a.).
c.) The footprint from the building does not have vertices on all of its corners! (Consider, f.e. the overlap of the northern triangle with the groundlevel structure). Manually re-creating a polygon to represent the "outline" becomes therefore difficult and leads to problems.
d.) As by the previous discussion, I'm trying to find a way where the data is not duplicated by a distinct "outline" polygon. Optimally, the correct outline would be obtained as a area-union of all building parts. This fails in this case, because the building parts are not disjoint, violating the MP validity conditions.

In any event, we should always take the Wiki with a grain of salt. osm.wiki/Relation:multipolygon#Multipolygon_created_by_only_one_polygon is another example which is questionable. Figure 11 calls this "ambiguous", which it is not (although there may be other reasons to prevent that situation).

The complaint of OSMI adresses the following type of situation osm.wiki/Relation:multipolygon#Touching_inner_rings which is considered O.K. in OSM. It is a mistake by OSMI to consider adjacent polygons in an MP faulty. There is no good reason to consider this a problem.

The duplication which I perceive is those of the perimeter edges: The consumer can already obtain the perimeter edges from a MP of the joined union of all building parts. Re-doing the edges as a separate polygon appeases OSMI, but makes editing more cumbersome, because now every edge on the perimeter is expressed by two polygons: 1. The adjacent building:part polygon and 2. The separate perimeter polygon.

I understand your concern and I will leave your "additional" polygon untouched where you add it, but on the other hand I think this practice subordinates correct data representation to problematic consumer (or validator) implementations. A MP which is composed of adjacent areas SHOULD be okay! OSMI should NOT complain about it! They SHOULD fix OSMI, not modify the data to remove spurious warnings.

I've improved several buildings in the vincinity of the CS, I suggest you ignore the OSMI warnings for the time being until the edits are stable, then feel free to add your polygons. I don't do it because it is a pain to do with iD and, by the above, I think it's the wrong thing to do.

You have created osm.org/way/1218755234 which is _not_ a MP but expresses the same area _as_ the previous MP osm.org/relation/16564239 Version 3.

This is duplicate information. To express the building outline/footprint, a MP composed of parts should be used, rather than creating a distinct perimeter polygon.

This question is SEPARATE from which "Simple 3D Buildings" approach is used. Since in this case, the building's footprint is the union of all of its building:parts, I used the method _without_ a type=building-relation. You decided to use the method _with_ a dedicated type=building relation.

Using an MP relation for a building which is composed of multiple building parts allows to combine the building parts into an outline *without* creating a redundant polygon which overlaps with the parts everywhere (permitted the parts don't overlap).

If you create a distinct polygon from the MP (because OSMI complains about the edges), then you get duplicated data and it's also less easy to edit.

That's why I think an MP relation is appropriate for the outline, despite the OSMI warnings; at least given the current assumptions.

Hello, the case with multipolys from adjacent areas seems to be a real problem for renderers. However, I would propose that this remain unchanged, regardless what OSMI complains about. Adjanced areas in MPs should be okay. The renderer should be fixed, if it has a problem with that.

Thanks for explaing and I can also confirm that the path is exactly as you mapped it. &2u

Where did you get this path from?

Annotation: They mean "not trace on aerial imagery" specifically HERE, where this background is available. In general (in areas where no such background exists), you can of course trace from imagery.

You can use 'Q' in the editor to make buildings rectangular. The ones you placed looks a bit crooked. Also, try to align adjacent buildings correctly - sometimes they share a corner and then become two separate lines, etc. Otherwise fine.
---

Published using OSMCha: https://osmcha.org/changesets/131883482

Cheers!

Yes, I'm sure. It's unpaved/[sandy] ground/sand. There are no construction works there.