[Tagging] Is landuse=conservation actually deprecated?

[Greg Troxel]

stevea <steveaOSM at softworkers.com> writes:

Thanks for writing back with a really helpful discussion.

> Contrary to what people might believe about me "pushing"
> boundary=protected_area (I am a co-author of the Park boundary
> proposal — and it is only a proposal right now, in draft form — this
> would "boost" boundary=protected_area, I'll abbreviate that as "b=p_a"
> here) as a tag that might NOT include a protect_class (though this
> isn't required as part of the proposal), as what Greg says below about
> "no real discussion, no vote and no legitimacy," I am a bit confused.

I think we are actually mostly on the same page; sorry if I was too
terse or misspoke.

I am 95% ok with boundary=protected_area and it has had a lot of
discussion.  I view it as entirely legitimate and have only a few minor
quibbles.

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.

To point out what I mean by 95% ok, my quibbles are basically:

  numeric codes are hard for hand mapping vs tokens

  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.

and note that I have similar thoughts about lots of tags, all not a big
deal.

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

> 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.)

> 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.

> 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).

> 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).

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.

  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.

  Ask the editor maintainers to remove the deprecation notion.


Is that a fair summary of common ground?

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201226/425327ee/attachment.sig>