Multipolygon (several outers) forest with different leaf_types: mapping strategy?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Multipolygon (several outers) forest with different leaf_types: mapping strategy?

David Marchal
Hello, there.

I mapped a forest made of several pieces of woodland, some contiguous and some isolated, with differents leaf_types. I mapped this (https://www.openstreetmap.org/relation/9393253) with a landuse=forest multipolygon, with common tags such as name and operator on the relation, and with leaf_type tags on the outer members, as each has a different value. It seemed a good way to model the fact that these woodlands were considered part of the same forest but had differents leaf_types, but I am unsure now: the JOSM validator claims that contiguous outer members is an error, and openstreetmap.org renders a misplaced name and no leaf_type. Is it a modelling failure or a renderer and validator error? In the first case, how should I map this?

Awaiting your answers,

Regards.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

marc marc
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 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)

Regards,
Marc

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

Joseph Eisenberg
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

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.

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 <[hidden email]> 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 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)

Regards,
Marc

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

Warin
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 <[hidden email]> 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 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

Markus-5
On Thu, 14 Mar 2019 at 01:24, Warin <[hidden email]> wrote:
>
> A site relation could be the best solution?

A group relation [1] seems to be the best fit. This is a relation for
a named group of objects. Unlike a site or multipolygon relation, a
group relation does *not* constitute a new object, but is merely the
name of its members as a whole.

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation

Regards

Markus

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

Andy Townsend
In reply to this post by David Marchal


On 13/03/2019 13:59, David Marchal wrote:
I mapped a forest made of several pieces of woodland, some contiguous and some isolated, with differents leaf_types. I mapped this (https://www.openstreetmap.org/relation/9393253) with a landuse=forest multipolygon, with common tags such as name and operator on the relation, and with leaf_type tags on the outer members, as each has a different value. It seemed a good way to model the fact that these woodlands were considered part of the same forest but had differents leaf_types, but I am unsure now: the JOSM validator claims that contiguous outer members is an error, and openstreetmap.org renders a misplaced name and no leaf_type. Is it a modelling failure or a renderer and validator error? In the first case, how should I map this?

Using a multipolygon relation like this makes sense when the objects are exactly the same, but not when they aren't, so that probably explains the validator issue.


Name placement on multipolygons like this is actaully a renderer decision - some will use one name per group of trees, some one name placed somewhere near the biggest.


I'd probably map your trees as either:


1) natural=wood; name=whatever; operator=whatever; leaf_type=whatever on each group of trees.  This will result in duplicated names, but isn't that different to the way we split roads when other tags change.


or


2) natural=wood; leaf_type=whatever on each group of trees, and create a landuse=forest multipolygon relation with name=whatever; operator=whatever that includes each group of trees.


or


3) If the "managed forest area" by operator=whatever includes significant area of no trees currently, natural=wood; leaf_type=whatever on each group of trees, and create a landuse=forestry multipolygon relation with name=whatever; operator=whatever that includes each group of trees or no trees managed by the same organisation.


The whole landuse=forest/natural=wood thing is fairly contentious though, so please don't take the above as "what everyone does in OSM"; it's just how I'd map it.


Best Regards,


Andy



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multipolygon (several outers) forest with different leaf_types: mapping strategy?

dieterdreist
In reply to this post by Markus-5


sent from a phone

> On 14. Mar 2019, at 09:20, Markus <[hidden email]> wrote:
>
> Unlike a site or multipolygon relation, a
> group relation does *not* constitute a new object, but is merely the
> name of its members as a whole.


actually it does constitute an object, a group, and the fact that there is a proper name underlines this. It doesn’t need tags to describe its nature, as that is defined through the members.


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging