[Tagging] Feature Proposal - RFC - boundary=forest(_compartment) relations
stevea
steveaOSM at softworkers.com
Thu Dec 31 00:45:34 UTC 2020
I'm glad to see Australia join Europe in "forest compartments being a thing," as they are quite foreign to my US English-speaking ear (and experience).
While they might be pursued as "a thing" in this proposal, I think it simply muddies the waters of what remains unsolved about "Forest" [1], a good discussion going on for many years. There are currently "six approaches" which are what can literally be described as "all over the map." I do think that this proposal must consider [2] below, which is months old and has associated recently successful (unanimous) Approval. Yes, some pay voting no heed. Some have also been working on this for years, it is slowly but surely being built.
Forward is difficult with six kinds of "forest" already. Answering Martin, I agree that forests have been here longer than we have (as humans). Personally, I "offer the respect of this distinction" to ancient or maybe cut long-long-ago "virgin" forests as natural=wood, reserving landuse=forest for "managed forest." That doesn't feel controversial to me as a starting point, though I know there are disagreements here and beyond. Data users, renderers often treat wood and forest similarly or the same. Data producers, mappers, find difficulty in being too specific. At least I do, beyond that "simplistic divide" between wood="more virgin" woods, forest=managed timberland. And in a wood, it is OFTEN true that "nature rules" with the raggedness of the boundary/edge (trees grow here), while with the forest, it is OFTEN true that "boundary rules" as a landuse (trees can be felled and/or forest products can be produced here). Saying more than that veers off in many directions (unfortunately of both misunderstanding and differing uses in our map).
Then we get into boundaries and plats and specific forests and named and numbered forests and how they render, even when weirdly shaped or fuzzily-specified and at what font size and it devolves into "hectic." So maybe marking boundary_stones and such as nodes that are distinctly verifiable is a place for forest(_compartment) to start. There is some larger work in the boundary and protected_area namespaces [2] going on right now, too. As a co-author, a serious goal of [2] is to simplify and harmonize syntax and semantics of protected_area boundaries, a tall order but we make good progress, imo.
SteveA
[1] https://wiki.osm.org/wiki/Forest
[2] https://wiki.osm.org/wiki/Proposed_features/Park_boundary
More information about the Tagging
mailing list