[Tagging] Feature Proposal - Voting - boundary=forestry( compartment) relations

Peter Elderson pelderson at gmail.com
Sun Apr 25 19:27:03 UTC 2021

In my opinion, the proposal should focus on just adding tagging for what is
in effect not tagged now: forestry areas including forestry compartments.

There are good arguments why it is not adequately tagged now, that is, data
users cannot be sure whether and how the land is used for forestry. The
current tagging of wooded areas is too ambiguous.

At the same time, it doesn't actually matter that landuse=forest is mainly
used as indicator that there are trees. It does present a strong argument
not to use landuse=forestry or boundary=forest. Using boundary is an
entirely different approach, unambiguous, I think. It does not require
retagging of the whole existing forest/wood database, but if an area is
improved in the way you propose, the result offers clear advantages (that's
what you have to present of course).

And that is something you can present to the data users, leaving it up to
them how best to profit and serve their users.

So I would say, leave out the deprecation thing, just keep the proposal
small and clean, no mixing of different objectives, and focus on the
unambigous added information and the advantages for the users. Do not
replace, but enhance.

PS I guess forestry_compartments are not necessarily numbered but can have
other labels? Nederland has forestry_compartments labeled A, B, ....I just
hiked through such a forestry area which, besides the labeled tree covered
areas, includes scrublands (with managed trees), lakes (with managed trees
in and around), sand dunes (with managed trees) and heath areas (with
managed trees).  Would these different areas also be forestry compartments?
They tend to have names rather than numbers or letters.

Peter Elderson

Op zo 25 apr. 2021 om 19:54 schreef António Madeira <antoniomadeira at gmx.com

> I totally agree with stevea.
> It was a tremendous proposal not only in participation but in its scope
> and documentation. I didn't vote because when I was about to do it I
> noticed my vote wouldn't make a difference, but it's clear the community
> thinks there's something here that should change and evolve to a next
> level. Kudos for not giving up with this mammoth task!
> Whichever the result will be at the end, OpenStreetMap will surely come
> out stronger and better.
> Regards,
> António.
> Às 04:26 de 25/04/2021, stevea escreveu:
> > These efforts are in the middle of a marathon.  I applaud what has been
> done so far, I applaud David's continuing efforts to "explain what might be
> done to solve."  I think this did break a record for participation, so the
> issue is both important and clearly a passionate one for many.  I find very
> inspiring the efforts to both craft good, new tagging and to understanding
> what we might improve.  The cycle repeats itself and OSM gets better and
> better.  Thanks to many for much!
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210425/a4b2d8ff/attachment-0001.htm>

More information about the Tagging mailing list