On 14/03/19 10:36, Joseph Eisenberg wrote:
Normally we should map features that are “real” and “current”, and is
easiest to do for things that can be observed in person.
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
+1
So then the problem is, how do you show that all of these patches of
trees are part of one “forest”?
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.
A site relation could be the best solution?
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.
Perhaps this is mapping land ownership parcels rather than a “real”
physical feature?
-Joseph
On Wed, Mar 13, 2019 at 11:14 PM marc marc <[email protected]
<mailto:[email protected]>> wrote:
Le 13.03.19 à 14:59, David Marchal a écrit :
> the JOSM validator claims that contiguous outer members is an error
yes it's- the sum of all outer should not have a "internal" way
like this one
https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713
so draw a new way for the outer of this part
or split currents ways to include only the outer part in the relation
and make another relation for the leaf_type
> openstreetmap.org <http://openstreetmap.org> renders a misplaced
name
It doesn't seem so misplaced
https://www.openstreetmap.org/#map=15/48.4222/5.9197
but that's not due to the tag
> no leaf_type
it's hard to render a forêt with several leaf_type
you may put natural=wood landcover=trees to every part of the forêt
having a different leaf_type
but you 'll have a duplicate forest : a foret at the relatin level
and
at every part. currently i'm not aware of a good schema to avoid this
(you can trick some QA tools by using landuse=forest for the
relationship and natural=wook for all parts, but see the wiki for
forest, the meaning of these 2 tags is random/variable depending
on the
mapper, the only meaning you can get is "there are trees", the same
meaning for the 2 tag)
-1. Best not to try and 'trick' things, gets confusing too quickly.
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging