[Tagging] Is landuse=conservation actually deprecated?

[stevea]

Note:  I include tedious amounts of in-line comments here to make crystal clear the conversation Greg and I are having.

On Dec 26, 2020, at 11:03 AM, Greg Troxel <gdt at lexort.com> wrote:
> What I think isn't ok is the "landuse=conservation is deprecated" and
> the subsequent effectively-mechanical edit as people just delete it
> without understanding.

Yes, our "common ground" certainly includes that "people deleting (anything) without understanding" (or without community discussion or consensus) isn't OK.  Especially when it comes to deprecating an entire tag.  That needs to be both discussed AND agreed-to, then documented.  That hasn't happened w.r.t. "landuse=conservation" or if it has, there is quite a bit of confusion about that.

> To point out what I mean by 95% ok, my quibbles are basically:
>  numeric codes are hard for hand mapping vs tokens

There is wide agreement that Contributors find protect_class numeric values more difficult than plaintext "tokens" (straightforward English strings).  This can be seen in the recently-approved SEZ proposal Voting section [1].

>  boundary=protected_area (should bd protected_area=yes) causes semantic
>  confusion about the object being the linear feature around something
>  vs being about the are within.  Obviously we are trying to tag the
>  inside area, not the line around, and in this respect this is like a
>  landuse= tag (but with protection vs use semantics).  But the very use
>  of boundary= IMHO has led to rendering showing lines/etc. rather than
>  a fill.

I am unaware of any proposal or usage of protected_area=yes as a tag.  If that tag is being promulgated anywhere or by anybody I'd like to know about it and better understand what the intended usage is.  I also discourage usage of protected_area=yes, as I find it confusing as well (for the same reason).  In the Park boundary proposal [2] mentioned earlier, the boundary=protected_area tag is suggested (and it is only a suggestion) to render with a thin green line, no fill, as "the boundary" of the protected area (hence, a tag of b=p_a).  It seems a straightforward semiotic for that semantic, expressed with that syntax.  Perhaps Carto rendering does that, perhaps not.  Perhaps the Park boundary proposal becomes approved, perhaps not.  These things are being discussed right now, that is OSM's proposal process at work.  There is no hurry (the proposal has been extant since September), there is plenty of time for reflection, dialog and any needed adjustment or correction if the community deems them necessary:  it is a draft proposal right now.

> And I have been happily adding b=p_a to conservation land, when I know
> that's how it actually is.

I believe that is correct, too.

>> I am not aware of an OSM conversation (or "movement") which is
>> otherwise "pushing" b=p_a.  I ask (please) for some evidence of that
>> so that I may read it, be aware of it and understand it.
> 
> Just from reading all the mail over the years, I have felt like there
> was a notion that everything to do with land conservation should be
> mapped with b=p_a and only b=p_a.  All other tags except
> leisure=nature_reserve and landcover tags should be removed in
> favor of b=p_a which is the one true tagging scheme.
> 
> Maybe that's a misread, and I am more than happy to forget all that with
> a good way forward.
> 
> (I should say that when there are multiple tagging approaches, and they
> really are tagging the same semantics, one winning, the other being
> deprecated, and moving over is just fine.)

A major intent of the Park boundary proposal is to BE that "good way forward," as it includes comprehensive tagging strategies going forward that are intended to vividly clarify what has been admittedly confusing.

>> I want to say "+1" here, but as that might be understood ambiguously,
>> I'll say I support the continuing use of landuse=conservation (where
>> appropriate) as well as boundary=protected_area (where appropriate,
>> today, also with a protect_class tag).
> 
> Thanks.  Agreed completey - I am 100% ok with boundary=protected_area
> being added when there is legal protection, and I do that myself now.

As an additional "bolstering" of this, you might review the Park boundary proposal and in its Talk page discuss any issues you might have with it.  That is an important part of the process of continuing community input about the draft proposal, which has been continuing for several months now.  Thank you in advance if you choose to do that.

>> I do not support "we aren't listening; you are wrong and we are going
>> to revert...".
> 
> Thanks.  Maybe I have misperceived, but it's felt that way to me,
> watching landuse=conservation being randomly deleted on parcels I have
> mapped in my own town by super-distant paid mappers, complaining, only
> to have another paid mapper from the same company do it again.
> 
>> I also do not support this (or other) editor changes which promulgate
>> wholesale deprecation of tagging, due to editors / tools whose user
>> interface / user experience elements actively deprecate tags.  I
>> characterize such "tool deprecation as highly aggressive behavior by
>> editor authors as they do not properly vet such deprecations with the
>> community.  Just because you author an editor does not mean that you
>> get to deprecate tagging, it is only the community, though consensus,
>> who should do that.
> 
> Agreed.
> 
>> Greg's "landuse=conservation and b=p_a wikis pointing to each
>> other..." solution seems entirely workable to me.  I entirely support
>> that, as it seems correct as both "having been done before" and "going
>> forward."
> 
> Sounds excellent to me, and I think each cross pointer should come with a
> "that other tag has semantics that are different" (and am guessing you
> do also).

Yes:  different tags (syntax) for different semantics ("meanings" of things in the real world) which produce different semiotics (symbols in renderings).  100% agreement.

>> Greg: I implore you and others who feel strongly about this to please
>> reconsider "stop"ping your participation in our project, as I feel
>> confident we can solve these issues.  Being a person who is involved
>> in at least some of the issues (as a proposal author of a relevant
>> issue, frequent contributor to wiki and mail-lists, a participant in
>> Mappy Hours, a speaker at national conferences...) I am optimistic we
>> can reach a solution that includes wide consensus.
> 
> Thanks -- I am not really that close to the edge.  I was just trying to
> point out that my experience with the deprecation, editors prompting
> people to delete, and non-locals deleting has been really unpleasant.
> This is in the context of OSM feeling like it is beginning to have more
> of a deletionist culture, after not having it feel that way early on (I
> started in 2009, so I missed the really early days).

I started in 2009, too, and we might both recognize that we've been around for "most" of the history of the project.  This "deletionist" culture you speak of does seem to becoming more of a trend in OSM.  If OSM is going to have good, smart growth in tagging (the point of this list), we should have very clear methods of how new tags which are intended to (or could) end up deleting existing tags have a very clear path forward of how "deletions" (deprecations) best take place.  We want to avoid disharmonious deletions that break existing toolchains and upset how users of "long-time," existing tagging schemes suddenly (perhaps) find themselves no longer able to find / see in the map data tags which they believe should be there.  I'm not sure I know a good place to look for "how OSM best does deletions of tags" as it is a topic that doesn't seem well-documented.  OSM seems to have a culture of its more long-term Contributors "just knowing what to do" in regards to deprecating tags, but I don't think this process is anywhere near explicit enough.  So, I think we should remedy that by being more clear about how (formally) deprecating tags takes place.  If there are such well-documented processes, I invite being enlightened as to where we clearly describe that.

> None of this is about the existence or meaning of b=p_a -- that's just
> fine, and if it had been added with deprecation and deletion, I wouldn't
> have felt the need to say anything, and would jsut have done that.
> 
> So where I think we are is:
> 
>  Adjust the wiki to document the longstanding practice of
>  landuse=conservation and remove the notion that it is deprecated.
>  Don't say that b=p_a has the same meaning.  Point out there that b=p_a
>  may be appropriate and should be added if so.

Yes, one tag, one meaning, but also able to be complemented with another (related) tag with a different meaning.

>  In b=p_a, point out that protection is not the same as a landuse, and
>  that a landuse should be added if appropriate, and that conservation,
>  forestry (active managent for timber production) or farmland are ones
>  to consider.

Yes, another tag, another meaning, also able to be complemented with another (related) tag with a different meaning.  Both wiki should point to each other and clarify the "related-ness" of these two tags:  how they differ, when it is appropriate to use one, the other and importantly, both.

>  Ask the editor maintainers to remove the deprecation notion.

I think so, yes.

> Is that a fair summary of common ground?

I HOPE so, yes!

SteveA

[1] https://wiki.osm.org/wiki/Proposed_features/Special_economic_zone#Voting
[2] https://wiki.osmp.org/wiki/Proposed_features/Park_boundary#Rendering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201226/706e4607/attachment-0001.htm>