[Tagging] Feature Proposal - RFC - boundary=forestry(_compartment) relations (Was "Feature Proposal - RFC - boundary=forest(_compartment) relations")

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Sun Feb 14 17:48:18 UTC 2021


I have several concerns with this proposal:

1. Deprecated use with already existing boundary and protected_area /
protect_class. It seems to me like an attempt to introduce yet another
duplicate use of boundary for a specific interest group.
As far as forestry, as a process, is concerned it's general
characteristics can be defined with an (already) defined protection
class: f.i. 15 - as a resources-protected-area or some of the
nature-protected-area classes. I am perfectly happy with the definitions
of the protection classes as they are not specific, neither
discriminating, which, to my opinion is not the case if you specifically
are going to use the term "forestry".

2. As mentioned in 1. the term as it is presented in this proposal seems
discriminating to me. Let me explain with an example: large parts of
forests in Africa and South-America are harvested, maintained using
similar management strategies as in forestry by indigenous tribes and
communities., however they are not considered forestry areas.  Forestry,
especially how it is described in your proposal, is a term introduced by
the western world. I know there is lots of confusion about the
landuse=forest tag but we should avoid to introduce an alternative which
caused a lot of objection and anger in the non-western world.
When people started mapping on OSM in Africa, these were mostly Western
expats and Western NGO workers. Africans started mapping tree covered
areas as forest, since that was the most common "western English
language" term they were used to. They were corrected in terms that we
should generally use natural=wood with the justification that most of
our forests are not managed or maintained.  You can see were the
commotion started, yet another western culture interpretation, that
indigenous people who live in and from the forest and many communities
surrounding them don't manage their forests. They do, for ages and very
successfully. It would be to bold to say better and more successfully
then in the western world.

3. It promotes the use of tagging a specific managed area combined with
other purposes, f.i. a managed wood through forestry with a protection
class of a different category. This is in contradiction with the
philosophy that we need to tag each mapped feature separately. In case
their is overlapping use or duplicate use of the same area, it is better
practice to map and tag them separately so we support the broadest range
of data consumers and renderers.

4. Their are other parts of the world and the environment, or resources
as you wish, were similar tagging challenges exist, in my area mainly
wetlands. Often these overlap, sometimes have the same boundaries with
wood covered land. So far we have been able to describe these different
land uses by using “natural=wetland” tags combined with boundary
relations. There was never a need for a specific “boundary” value like
“ramsar” or “wetland_managed”. If there is a specific or broad used need
it can be perfectly done by atrribution of the boundary or the natural
areas. F.i. ramsar = yes does exist and is used. Which leaves the
tagging and mapping applicable for different cultures and policies in a
non discriminating way as is largely supported with the protection
classes provided in our wiki.

This leads me to my positive support of this proposal as it attemps to
deprecate landuse=forest and all its commotion that has grown around it
in competition with natural=wood. That I fully support but replace it
with a non-discriminating, already existing but hardly used value like
protect_class=15. I propose to make a specific wiki page for
protect_class = 15 and add attribution for a specific sector or use
case. Try to strive for a general tagging strategy that fits all and
propose solutions with attribution for more specific or culture inspired
practices.

Regards, Bert Araali.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210214/27ab57b0/attachment-0001.htm>


More information about the Tagging mailing list