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.

Consider what is written below, see also the figure

osm.wiki/Relation:multipolygon

Island within a hole
From the possibility of having multiple outer rings in one relation, it also follows that you can easily model "islands" within a hole:

<relation id="1">
<tag k="type" v="multipolygon" />
<member type="way" id="1" role="outer" />
<member type="way" id="2" role="inner" />
<member type="way" id="3" role="outer" />
</relation>

A construct like this would previously have required different multipolygon relations, one with way 1 being outer and way 2 being inner, as well as one with way 2 being outer and way 3 being inner. Such cascading is still needed when the "island" in the middle is something else than the area on the outside, but where the "island" is the same stuff it can just be made a hole in the hole. Beware though, that following this method, still a dual determination of the area mapped by way 3 will be created, as the hole and the island DO overlap!

Evidently your brain is superior to that of others.
I did not meditate your data, but simply specified that the holes in the inner area of the polygon are still forest in compliance with the rules of multipolygons.

In OSMI
http://tools.geofabrik.de/osmi/?view=areas&lon=15.80947&lat=47.73963&zoom=14&baselayer=Geofabrik%20Standard&opacity=0.67&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

Sorry... with DeepL Translate

Hallo,
Mit Ihrer Version des Multipolygons haben Sie interne Inseln mit nicht beschreibenden Löchern erstellt.

Deshalb warnt das OSMI vor dem Fehlen von Beschreibungen.

Die Regeln für die Konstruktion von Multipolygonen finden Sie hier:

osm.wiki/Relation:multipolygon

Insbesondere der Hinweis auf die "Island within a hole".

Hi,
With your version of multipolygon, you have created internal islands with nondescript holes.

This is why OSMI warns about the lack of description.

The rules to be adopted for constructing multipolygons are here:

osm.wiki/Relation:multipolygon

In particular the one referring to: "Island within a hole"

Salve,
Con la tua versione del multipoligono, hai creato delle isole interne con dei buchi non descritti.

Per questo OSMI avverte della mancanza di descrizione.

Le regole da adottare per la costruzione dei multipoligoni sono qui:

osm.wiki/Relation:multipolygon

In particolare quella riferita a:"Island within a hole"

Replica

Prova commento