Buon giorno,
Attenzione hai modificato il nome della strada "Via Papa Giovanni Ventitreesimo" non rispettando le convenzioni sui nomi che trovi qui:
osm.wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
Cordialmente

Forse ho risolto il problema

Salve,
Mi dispiace per quanto successo, stavo appunto modificando la relezione
relation/10452441
escludendo dall'area agricola i fabbrticati e la relativa area di pertinenza.
Noto che nella nuova relazione che hai creato
relation/16878352#map=15/44.3896/7.4763
ci sono ancora tante aree comprendenti fabbricati da escludere.
Non so come risolvere il problema per non perdere tutto il lavoro fatto, se ritieni opportuno puoi fare anche un revert

Actually, the helipad is a structure that rests on the roof of the building.
You are absolutely right when you assert that one should not mix heights with levels.
However, it seems to me that modeling with fractions of a floor is not possible.
I have tried to improve the representation of the Helipad structure as an inverted truncated cone.
The walkway joining the helipad to the highest part of the building is still missing.

I am sorry, it was not my intention to modify the structure.
I was testing in JOSM the 3D modeling of the building and accidentally sent the test data.
In JOSM the conventional height of a floor is considered 2.5m while in F4map they consider 3.0m this height.
In fact in F4map currently the heliport intersects with the building.
I corrected the heights taking into account the conventional measurement of a floor according to F4map.
Therefore the structure should be displayed correctly shortly.

Good job now it seems there are no problems, congratulations especially you used as ID editor.
But if you intend to continue with 3D mapping I would recommend JOSM where you can work on a single object without the many data in the area.

It is absolutely true that three-dimensionally there is no contact between the parts.
It is also true that I can define the perimeter of a part with a larger number of nodes without distorting its geometry.
If I then drop nonessential points on the same coordinate, I use only one to avoid the reporting of duplicate points.
The parts thus defined will then be in contact or not, with each other, depending on the tags entered on the way.

The multipolygon is not needed and you can eliminate it.
You have to create a point of contact where the paths intersect

way/1218545045 with way/1218545046
way/1218545043 with way/1218545044

This way you will be able to create the "outline" of the building, to be included in the building report as an "outline"

For the helipad not having specified the thickness of the plot, in JOSM, it seems to start from the ground.

Hi,
You are mapping a building for 3D rendering.
You have rightly used a building type relationship to group the parts of the building.
You created a relation type multipolygon to group the parts of the ground floor and then inserted it into the building relation as an "outline" member.
This relationship is not necessary for two reasons:
1 - The parts of the building are already found inserted in the building relation.
2 - The multipolygon does not represent the perimeter of the building projected on the ground (Top View).

As you can see, the absence of the outer perimeter, does not allow the proper 2D rendering of the building
relation/16603276#map=18/47.49661/9.74649

At present, even the 3D rendering does not reflect the building outline
https://demo.f4map.com/#lat=47.4966370&lon=9.7454901&zoom=20&camera.theta=67.108&camera.phi=-1.432

You can also notice the lack of the minimum level on the part representing the helicopter pad.

If there are rules it seems to me that they should be applied.
If they are wrong it is equally true that they should be changed.

OSMI verifies compliance with the MP construction rules.
Then the MP rules described in osm.wiki/Relation:multipolygon should be changed.
In any case for 3D mapping of buildings as in this case, the rules detailed in
osm.wiki/Simple_3D_Buildings

In the relation
relation/16564239 Version 4
data are not duplicated, because they already exist on the perimeter
way/1218755234
which delimits all parts present in the building report.
In this case, it is advisable to apply the rules of "Simple 3D Buildings" that avoid reports in OSMI for incorrect use of MP rules

No redundant multipolygon is created.
Only one building multipolygon is used to join the various parts.
On the outer perimeter, of the building, the common data of the building is entered.
You don't need the "Relations of type multipolygon" multipolygon in fact I transform it to "multipolygon tagged with building=*"
osm.wiki/Simple_3D_Buildings

Hi,
The multipolygon (MP) relationship is generally used for areas.
osm.wiki/Relation:multipolygon
For mapping buildings in 3D, the use of building relationships is appropriate
osm.wiki/Simple_3D_Buildings
Use of the buildings relation facilitates rendering of buildings without flagging in OSMI
https://demo.f4map.com/#lat=47.4957691&lon=9.7460920&zoom=21&camera.theta=65.103&camera.phi=-51.462
https://tools.geofabrik.de/osmi/?view=areas&lon=9.74663&lat=47.49629&zoom=18&baselayer=Geofabrik%20Standard&opacity=0.19&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
Greetings

Now they are connected to the roof
way/15805226
OSMI should not report problems at the multipolygon

Ciao,
Avendo rimosso il buco centrale, il multipoligono è diventato un semplice poligono.
https://osmose.openstreetmap.fr/en/issue/6f626144-7fe6-7728-9285-bae2a67b68de
Andrebbe quindi eliminata la relazione. Puoi anche considerare di inserire il tag "garden:style=flower_garden"

Ciao Đuro Jiří,
Ho modificato la tua mappatura in quanto la relazione relation/16087959 violava le regole dei multipoligoni osm.wiki/IT:Relation:multipolygon.
Naturalmente sono stato tratto in inganno dalle foto aeree ed ho mappato la superficie come coperta da ghiaia.
Dalla foto allegata appare che la superficie mappata è una aiuola fiorita senza "il buco centrale" pertanto sembra più appropiato l'uso del tag "landuse=flowerbed" senza l'annello interno.
Cosa ne pensi?

I merged the multipolygons of the rocks, removing the relationship with fewer members and the segments no longer needed. Updated the resulting relationship (one outer and two inner areas).

Hello,
Today OSMI
https://tools.geofabrik.de/osmi/?view=areas&lon=10.52738&lat=46.15749&zoom=15&baselayer=Geofabrik%20Standard&opacity=0.63&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
Reports problems at the bare rocks multipolygon.
That area is described by two multipolygons
relation/12991396
relation/12991394
which could be unified by removing the segments
way/1184255723#map=17/46.15989/10.52399
way/1184255725#map=15/46.1587/10.5231
and the straight part of the segment
way/1184255724

Hi,
Simply OSMI was reporting the presence of 2 nodes in the same location.
By doing the Merge between nodes one was removed as it was redundant.
Vedi https://resultmaps.neis-one.org/osm-change-viz?c=136818872#21/47.35353/8.51060
I see that you entered the area as "place"
way/117778756
In this case JOSM reports the omission of the name.
Regards