Salve,
Non capisco il motivo di questo commento.
Ho eliminato un percorso che ho inserito per chiudere un multipoligono, che in seguto al ripristino dei dati è risultato inutile.
Non dovevo farlo?

Stammi bene

The glacier area "Vedretta del Mandrone" was included by @Edoardo%20Zanotti with way/888903146 in the multipolygon relation/3320630#map=13/46.1616/10.5284. This change resulted in an OSMI report for duplicate segments, which I corrected without changing the extent of the area.
If you know the boundary of this glacier edit the incorrect portion.

Ciao,
Mi permetto di segnalarti i problemi rilevati da OSMI in merito ai tuoi recenti inserimenti di dati.
https://tools.geofabrik.de/osmi/?view=areas&lon=9.66926&lat=45.84349&zoom=16&baselayer=Geofabrik%20Standard&opacity=0.20&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
Tra le altre cose hai creato la relazione relation/14962927 per delimitare/unire aree che non risultano omogenee utilizzando le etichette:
landuse=religious
name=Ghiaia
type=multipolygon
Immagino che le aree, ragruppate insieme,non abbiano niente di religioso e il loro nome non sia Ghiaia.
Ritengo pertanto sia più appropiato l'uso di:
surface=fine_gravel
escludendo, naturalmente dalla relazione, le areee con superficie di tipo diverso.
Le regole per la creazione dei multipoligoni le trovi quì osm.wiki/Relation:multipolygon
OSMI segnala anche che il perimetro della relazione non è chiuso e ci sono sovrapposizini di aree.
Per evitare questi inconvenienti è opportuno non ignorare gli avvertimenti dell'editor in fase di caricamento dei dati.
In loco hai anche creato una relazione che ragruppate tutte le aree pedonali (marciapiedi), non compredo la motivazione di questa scelta, che oltre tutto, rende difficile la modifica/manutezione visto l'estesione e il numero dei membri.

Served by a road that is not propitiously agricultural are a restaurant, a church, a castle, and a farm. I am reasonably convinced that patrons can access them with their own vehicles (motocar=destination).

Hallo,
OSMI berichtet derzeit:
https://tools.geofabrik.de/osmi/?view=areas&lon=16.73389&lat=47.95795&zoom=18&baselayer=Geofabrik%20Standard&opacity=0.40&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_no
Nicht alle Probleme gelöst
Grüße

Ciao,
Vecchia espressione inglese DIRFT: Do it right first time every time (Fallo bene la prima volta ogni volta.)

Indubbiamente si tratta di una costruzione sul mare e non di un edificio.

Il ragruppamento delle parti di questa costruzione in una relazione multipoligono non è indicata perchè ne verebbero violate le regole. La possibile soluzione, per ragruppare le parti, è quella di usare una relazione building (non edificio ma costruzione). Come è evidente la soluzione adottata ha eliminato la segnalazione di OSMI, pertanto non la definirei sbagliata.

La descrizione della struttura è incompleta da ben 3 anni, evidentemente ne eri a conoscenza, ma non hai cercato di migliorarla come specificato più sopra, potevi benissimo aggiungere man_made=pier alle sue parti con gli opportuni tag.

Salve,
La dimensione della spiaggia dipende dalla marea, ho modificato "intermittent" in "tilad", altrimenti JOSM segnala l'abbinazione non corretta dei tag.
Giustamente la spiaggia è un membro inner della relazione zone umide, ma anche inner della relazione "coastline". Attualmente al posto della spiaggia viene renderizzata l'acqua.
Se concordi si può procedere alla modifica.

Salve,
Mi sono imbattuto in questa relazione tipo "site" che raggruppa i numeri civici dei Casoni di Grado.
Visto che fondamentalmente sono degli indirizzi forse è il caso di trasformarla in tipo "associatedStreet" magari col nome abbreviato in "Casoni di Grado", sperando che vengano localizzati dalla ricerca dell'indirizzo con "OpenStreetMap Nominatim".
Ciao...

Molto bene, però rimango alquanto perplesso:
Hai ottenuto le risposte ai tuoi perchè.
Sorvoli sul fatto che hai inserito dei dati e quindi in segiuto anche rimossi in modo inadeguato.
Chiedi agli altri di fare ciò che non hai fatto.
Ma...strano atteggiamento.

Hi Luzandro,

Let's see if we can solve this problem.

You have removed an inner ring of the relation (relation/13029199#map=18/47.71129/17.00425) believing it to be wrong, leaving the removed ring without any tags.

The problems present were not resolved as:

OSMI for multipolygon reports (https://tools.geofabrik.de/osmi/?view=areas&lon=17.00455&lat=47.71124&zoom=19&baselayer=Geofabrik%20Standard&opacity=0.71&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)

JOMS using the update multipolygon tool warns that the inner rings of the multipolygon are touching in at least one place.

It is clear that the mapping technique used, which in each case involves mapping all adjacent areas, in this case creates problems reported by the two validators.

I have verified that in order to override the validators' warnings, it is appropriate to use the area multipolygon construction rules where it is specified that the inner rings should not touch each other.

In the forest there are four inner areas, three adjacent areas and one separate area.

Currently only three areas are mapped missing the inner area of the forest (reported by OSMI).

The ring you removed was supposed to represent this area, with its proper tag, inserted as an inner ring member of the relation (in which case everything would be OK for OSMI).

The problem arises using JOSM's multipolygon update tool, which removes the tag from the ring because it is equal to the outer area of the multipolygon, also signaling that the inner rings are touching.

Instead using only two inner areas that are part of the multipolygon, with one of those areas filled by the three adjacent areas that are not, of course, part of the multipolygon solves all the data consistency problems.

I am sure you will want to verify that the above is true.

Buongiorno,

Ricostruzione dei fatti:
In quell'area prativa avevi inserito una ulteriore area per l'apiario inserendola come inner della foresta.
OSMI ha segnalato puntualmente un problema dei dati inseriti nel multipoligono.
Ho risolta la segnalazione creando un buco nell'area descritta del multipoligono foresta, riempiendola quindi con un multipoligono prativo con al suo interno l'area dell'apiario.
Tre anni fa hai cancellato l'apiario lasciando la relazione prativo con un unico membro esterno.
Recentemente hai cancellato la relazione che caratterizzava l'area prato con la conseguenza di lasciare un buco nel multipoligono foresta, hai quindi modificato il buco come area prativa.

Noto che il multipoligono foresta è stato aggiornato più volte da parte tua e che ci sono state diverse segnalazione di OSMI per problemi creati al multipoligono. Dovresti prestare più attenzione quando modifichi i multipoligoni specialmente quando sono di notevoli dimensioni. Non è sufficiente conoscere i luoghi, ma i dati devono essere inseriti rispettando le regole, in questo caso, di costruzione dei multipoligoni.

Buon mapping!

OK! Then see to it personally that YOUR? multipolygons are updated according to the findings of the discussion, otherwise make explicit a valid reason for not doing so.
I highlight, once again, that a multipolygon only carats its outer area, while the inner area(s) must all be different from the outer area. Because of the above, special care must be taken not to include as internal areas of a multipolygon areas equal to its external area. Finally, in the specific case you have not included the two areas covered by forest (missing perimeter and tag).

I never questioned that those areas are forest. I tried to INSERT the areas with correct tags but having, at the end before loading the data, used the JOMS Update Multipolygon Tool I did not realize that these tags were removed with the now known result.
In the original mapping, the area had not been included (wrong) settling for visualizing a virtual area (thus not present in the data) thanks to the render (you don't map to the render).
I hope I have made myself clear by summarizing:

OSMI is very strict in checking the inner areas of multipolygons, in fact it punctually reports the presence of empty areas between the inner rings that touch each other. I would not call this behavior a known Bug.
It is wrong to intentionally leave gaps between the inner areas of multipolygons because the render shows what is expected.
JOSM generates problems with the Update Multipolygon Tool when among the inner areas of the multipolygon it finds an area with the characteristics of the outer area of the multipolygon (it removes the tags to the area ring since it is already present in the characteristics of the multipolygon).
It follows that if in JOSM we use the Update Multipolygon Tool the inner areas, with characteristic equal to the outer area of the multipolygon, these are not displayed by the render because they are considered empty (ring without tags).
To avoid the problems in these cases, the way to go is to create a large area inside the multipolygon, then insert the micro areas that make it into this newly created area. In this way, data validations by OSMI and JOSM will not give warnings, and the renders will display the areas correctly.
In multipolygons use mapping with adjacent inner areas only IF there are no holes between areas AND the areas are all different from the outer area.

If there are no contraindications I will update the multipolygon as it still has empty areas highlighted by OSMI

In fact, we are discussing it. The rules depend neither on knowledge of the language or the region but on their knowledge.
My edit did not break or change the input data but added a annel to signify that area is not empty. The mapping style created an undefined area that renders still display but that OSMI flags as possibly missing an outer annel. By entering the missing area as a forest and validating the data with JOSM it removes the tags from the annel as they match those in the multipolygon. After this change OSMI no longer reports this area as empty. OSMI cannot know if an empty area is left so intentionally or instead is a plotting error and rightly reports it. It does not seem appropriate to leave an area blank and rely on the render to display it. Therefore, I do not think it is appropriate to use this way of mapping in the case of multipolygons where you do not completely define all the adjacent interior areas. I would be a little more cautious about calling my mapping an error and deeming the one currently applied to the area to be correct.

Hi Luzandro
Let me preface this by saying that I use an automatic translator so maybe we don't understand each other.
You have written a whole treatise to justify the use of a mapping mode that is not recommended because it also creates problems when validating data with both OSMI and JOSM and perhaps to rendering software.
While restructuring the data as you mentioned and for that matter also the way described by WIKI, using a multipolygon with an outer and an inner perimeter to enclose the forest area getting the advantage of reducing the members of the multipolygon and also making it simpler. Then the area enclosed by the inner perimeter can be filled in at will without creating any problems for both OSMI and JOSM data validation and that will be rendered correctly. As you can see, the thing seems simple and trivial to me.

It is true, however, in between there cannot be empty areas.

I disagree this is your opinion.

What you write does not correspond to the truth. Check OSMI`s reports on the affected area now.

http://tools.geofabrik.de/osmi/?view=areas&lon=15.83117&lat=47.73110&zoom=13&baselayer=Geofabrik%20Standard&opacity=0.71&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

A review never hurts.
However, it is not recommended to create inner eras formed by small adjacent areas as in this case.
You left in the middle of these adjacent areas two unspecified areas.
To avoid creating problems you should have drawn one large inner area, then filled this created hole with the various ground covers that would obviously not be part of the forest relationship.