<div><div dir="auto">Normally we should map features that are “real” and “current”, and is easiest to do for things that can be observed in person. </div></div><div dir="auto"><br></div><div dir="auto">This suggests mapping each patch of trees as a separate polygon or closed way, based on having the same leaf_type and leaf_cycle. Usually it’s only necessary to use a multipolygon when there is a hole in a donut-shaped woodland. Each area should be tagged natural=forest or natural=wood in addition to the leaf_type/leaf_cycle tags</div><div dir="auto"><br></div><div dir="auto">So then the problem is, how do you show that all of these patches of trees are part of one “forest”?</div><div dir="auto"><br></div><div dir="auto">How can another mapper verify where the named “forest” ends? Is it a type of boundary=protected_area that is designated by the local government or private landowner? Is there a fence around the whole area? It looks like it is not a single continuous area, so this makes it even harder to verify where the named forest ends.</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">I don’t know much about the original poster’s example, but it looks like the name is “<Village name> Communal Forest”, and the areas included in the relation are on separate sides of the village and divided by farmland. Also, there are other areas of woodland right next to the edge of this forest.</div><div dir="auto"><br></div><div dir="auto">Perhaps this is mapping land ownership parcels rather than a “real” physical feature?</div></div><div dir="auto"><br></div><div dir="auto">-Joseph</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 11:14 PM marc marc <<a href="mailto:marc_marc_irc@hotmail.com">marc_marc_irc@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 13.03.19 à 14:59, David Marchal a écrit :<br>
> the JOSM validator claims that contiguous outer members is an error<br>
<br>
yes it's- the sum of all outer should not have a "internal" way<br>
like this one <br>
<a href="https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713" rel="noreferrer" target="_blank">https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713</a><br>
so draw a new way for the outer of this part<br>
or split currents ways to include only the outer part in the relation<br>
and make another relation for the leaf_type<br>
<br>
<br>
> <a href="http://openstreetmap.org" rel="noreferrer" target="_blank">openstreetmap.org</a> renders a misplaced name<br>
<br>
It doesn't seem so misplaced<br>
<a href="https://www.openstreetmap.org/#map=15/48.4222/5.9197" rel="noreferrer" target="_blank">https://www.openstreetmap.org/#map=15/48.4222/5.9197</a><br>
but that's not due to the tag<br>
<br>
> no leaf_type<br>
<br>
it's hard to render a forêt with several leaf_type<br>
you may put natural=wood landcover=trees to every part of the forêt <br>
having a different leaf_type<br>
but you 'll have a duplicate forest : a foret at the relatin level and <br>
at every part. currently i'm not aware of a good schema to avoid this <br>
(you can trick some QA tools by using landuse=forest for the <br>
relationship and natural=wook for all parts, but see the wiki for <br>
forest, the meaning of these 2 tags is random/variable depending on the <br>
mapper, the only meaning you can get is "there are trees", the same <br>
meaning for the 2 tag)<br>
<br>
Regards,<br>
Marc<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div></div>