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

[Mateusz Konieczny]

Feb 10, 2021, 09:45 by tagging at openstreetmap.org:

> Now, let's say the proposal
> * deprecates landuse=forest,
> * states that natural=wood says "this area, managed or wild, is totally covered by trees",
>
Seems fine to me. Note that it requires no action at all from data consumers,
they can keep rendering natural=wood and landuse=forest.

> * states that boundary=forestry says "this area is managed through forestry".
>
It would be worth explicit documenting that forestry includes not only logging.
Active forestry may be happening in area without logging, without plans for
commercial exploitation of forest (or use of forest for purposes other than
production of timber and related materials).

What about privately owned forests?

Long time ago someone imported areas officially considered as forest parcels in Poland,
result was often a bizarre mess (barcode pattern of narrow strips of land was very popular
- 100m long, 5m wide plot owned by National Forestry, 5m wide plot owned by
private owner, 5m wide plot owned by National Forestry, repeated 50 times).

Especially if in some areas boundary=forestry would be worth rendering,
how it should be handled that in some areas it would merely record land ownership
and nothing else? And rendering it would be useless and harmful there?

Also, how it is supposed to be mapped/verified?
If one sees 45 years old trees - how one can recognise is it maintained
commercial forest, nowadays protected area, abandoned private forest without
forestry, private forest without forestry because it is not needed right now
or something else?

Would it be OK to map this also when this boundaries has no traces at all on the ground
and importing them is the sole source of obtaining this data, with independent
verification being impossible?


> Let's take the above schema, with ║ symbolising the boundary=forestry relation, and ─ symbolising natural=wood, the only remaining tag for wooded areas:
>
What about landcover=trees? Would it be also deprecated?



> I'll try to explain through ASCII art (to be quick; should what I explain be merged in the proposal, I would take time to draw nice schemas). Let's say there is a pond (│ symbol) in the forestry area, modelled with landuse=forest (─ symbol), and the pond is considered part and parcel of the forestry area. Currently, the landuse=forest and water=pond polygons would overlap:
> ─────────────────────
> ─────────────────────
> ───────┼┼┼┼┼┼────────
> ─────┼┼┼┼┼┼┼┼┼───────
> ───────┼┼┼┼┼┼┼┼┼─────
> ───────┼┼┼┼┼┼┼┼──────
> ─────────────────────
> This mapping allows to model the fact that the pond is considered part and parcel of the forestry area.
>
This is an incorrect tagging caused by using landuse=forest to map forestry area

> Unfortunately, this often leads to a somewhat buggy rendering, with trees symbols rendered in the water.
>
This is deliberate to show that tagging is buggy.

See
https://github.com/gravitystorm/openstreetmap-carto/pull/1242
https://github.com/gravitystorm/openstreetmap-carto/pull/1728


> That may be perfectly OK for wooded residential areas
>
Yes, it is also deliberately done this way to try supporting tree-covered
areas of various kind.


> The proposal could be about "landuse=forest is managed, natural=wood is unmanaged. Period.", but, as I understand the situation, such proposal would likely stall or being uneffective, because most mappers who use another approach of the landuse=forest/natural=wood distinction would likely keep their approach, voiding the proposal, even approved. That wouldn't resolve the pointed rendering issues either.
>
Alsowhat about
- people mapping forest from aerial images
- not interested in this distinction
- unable to survey situation
- ones overwhelmed by complexity
?

(also note that it is extremely hard to fing forest that is not managed - typical protected forest
is also managed in some way)

There must be a way to mark "I mark that there are trees here" without making
mandatory to specify anything else.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210210/6abf0af5/attachment.htm>