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

[Peter Elderson]

David Marchal via Tagging <tagging at openstreetmap.org>:

> I hereby suspend the vote, as it is clear that consensus will not be
> reached on the proposal in its current state.
>

Do you mean to say after adaptation the voting will resume at the same
point? I think the proposal will change enough to warrant a new vote.


> The main issues that currently prevent reaching a consensus are, according
> to the vote comments, the following:
>
>    1. the proposal statement about using databases to map forestry area
>    boundaries, which is considered by some allowing unverifiable mapping. It
>    is a huge issue for some mappers, although others pointed out that
>    verifiability is, particularly in so-called third world, very subjective.
>    The proposal will be modified towards stronger verifiability, as this
>    barrier is currently strong enough to prevent, by itself, consensus on the
>    proposal (though this will not prevent users, in case of approval, to adapt
>    the verifiability criteria to the reality of their area);
>
> You could simply state that verifiability is important (link to relevant
wiki) and especially so when using external information/databases (link to
relevant wikipages about import documentation, licensing), and that it is
up to local communities to judge reasonable verifiability in their area.


>
>    1. the proposal does not enoughly state how would the transition to
>    the new scheme be done. I kept that out of the proposal, because I felt it
>    was irrelevant, but it seems that this is necessary out of pedagogy. Given
>    the complexity of the proposal and the wide impact it will have if
>    approved, understanding it upon first reading is essential to allow voters
>    who did not participate in preliminary debates to better understand what it
>    is about, without having to dwelve in all the details; I'll then include
>    some sort of transition digest, especially a table which will explain how
>    to update the tagging in different situations, and a detailed argumentation
>    of the design choices made in the proposal (why boundary=* and not
>    landuse=*? why deprecating landuse=forest? why not a landuse=forestry?…);
>
> Too technical. It's not a technical problem, it's organisational. You need
to manage the change. It's not enough to edit a few wiki pages.

>
>    1. some voters are attached to landcover=trees. I was not able to
>    understand this attachement during preliminary debates: I presented
>    arguments to some such mappers during the preliminary debates to spark
>    debate about it, but did not receive a counterargumentation I could
>    understand. Still, there are mappers that opposed the proposal solely
>    because of this deprecation, so I assume I must make more efforts to try to
>    understand these mappers and determinate if this attachment to
>    landcover=trees is a matter of reflection (in which case, shoud the
>    proposed changes be modified or should the proposal simply explain clearer
>    the deprecation)?, or a mere not-argumentable personal opinion ("I feel it
>    better, period.").
>
> Your proposal starts with:
Definition: relation for mapping forest management (forestry) area
boundaries, independently of landuse
<https://wiki.openstreetmap.org/wiki/Key:landuse>/natural
<https://wiki.openstreetmap.org/wiki/Key:natural> tags

If it's independant, then restrict the proposal accordingly. Deprecation is
not "independant". I think a recommendation (based on expertise) how to use
the landcover/natural/landuse/leisure/whatever tags for forestry areas is
warranted, your views are probably shared by many, but redefining /
deprecating tags with huge usages is not, because other views are also
shared by many.

Please, dear mappers, help me to build consensus; for that, we need
> arguments, not assertions.
>

You also need to look behind arguments. History, installed base, other
drives and emotional attachments cannot be taken away by cerebral
arguments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210218/b757e01a/attachment.htm>