[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Paul Johnson]

Not to say that tag popularity means it's the best way forward.  Consider
that the US is still dealing with an import on low quality TIGER data and
continent-wide smash-tagging by one person affecting how newer people use
highway=motorway and highway=trunk.

On Wed, Nov 28, 2018 at 5:09 PM Doug Hembry <doughembry at hotmail.com> wrote:

> On Wed, Nov 28, 2018 at 11:55 AM Paul Allen wrote:
>
> Everyone seems to have forgotten boundary=administrative with its
> associated admin_level=n tag, which IMHO is pretty analogous to
> boundary=protected_area with its protect_class=n tag.
>
> I didn't forget it. I neglected to mention it because I didn't feel like
> opening both ends of a can of worms and figured one end was enough. Now
> that you raise the issue, I don't like the numbers in admin_level, but at
> least they are sort of hierarchical, whereas protect_class is not, and
> there are very few of them. They even both have look-up tables by country.
> And the class numbers are
>
> not arbitrary, Mateusz, - they map to IUCN categories.
>
> That wasn't clear to me from the documentation. I inferred that might be
> the case but I didn't see an explicit mention. Then again, there is way too
> much documentation to wade through before I saw a mention of IUCN at all.
> That ought to have been made clear in the introduction, probably the first
> paragraph of the introduction, and maybe the first sentence of that
> paragraph. But that still wouldn't redeem it. But seriously, how many
> aboriginal lands do you think a mapper would
>
> have to tag before they remember "protect_class=24"?
>
> How many mappers handle nothing but aboriginal lands? Are there so many
> aboriginal lands that even one mapper could deal with those and have time
> for nothing else? I'd guess that most mappers try to deal with everything
> in a locality they're mapping. But protected areas are rare and you're
> asking people to remember ALL of those magic numbers in case they come
> across a nature reserve, or aboriginal land, or any of dozens of other
> things.
>
> And, as for the future archaeologists, and "human readable": Correct use
> of the boundary=protected_area tag actually requires the use of
> protect_title=* tag that provides users with the human readable title of
> this area-type (note: not the "name", which may also be present). ie,
> protect_title= Indigenous Protected Areas, or Indian Reservations, or Terra
> Indigena, or Territorio Indigena, etc,..
>
> The protect_title is duplicating information in the class. So you're
> asking a mapper to type in (and possibly get wrong) what should be a
> look-up mechanism. Either protect_title is unnecessary or protect_class is.
> Unless, of course, protect_class is so broad that protect_title is needed
> to flesh it out, in which case protect_class is useless.
>
> But although I don't buy your "numbers are bad" argument [...]
>
> Numbers are bad. Not always, of course. building:levels is numeric. Most
> house numbers are purely numeric (only most, because of things like 12A).
> But magic numbers, which IUCN are, are bad in a human interface. They are a
> good way of reducing storage in a database (at the expense of compute
> resources) so might be appropriate there, hidden from the eyes of all but
> the database coders. What you're asking for means that, to make the thing
> human-friendly, EVERY editor has to have a look-up table so mappers can be
> presented with a list of comprehensible choices like "aboriginal lands"
> which get mapped to protect_class=24. What you're asking for is that EVERY
> data consumer has to have a look-up table so humans get to see that an area
> on the map is aboriginal land rather than protect_class=24. Technically,
> it's possible; realistically it won't get implemented in all applications.
> The "numbers are bad" assertion worries me and prompts a broader question:
>
> if this is "policy",
>
> It is not (as far as I am aware) a policy. It is the feeling of a number
> of people here that magic numbers are a bad idea. I suspect that many of
> those people base that feeling, as I do, upon experience of programming
> and/or user interface design.
>
> does it mean that boundary=protected_area, and protect_class=* tags are
> doomed in OSM?
>
> I wouldn't say they're doomed, but I doubt they'll get universal adoption
> as the primary way of tagging such things, particularly if tags such as
> aboriginal_lands gain approval. This discussion isn't the first time I came
> across protect_class etc. Some time ago I looked at how to map a nature
> reserve and saw the choices were incomprehensible mess of protect_class and
> friends or leisure=nature_reserve. Guess which one I chose. I have no
> objection whatsoever if you wanted to introduce a tag like IUCN=*. In fact,
> I think it would be a great idea. Mappers who care about it could use it
> set. Queries with overpass-turbo could use it. Nice idea. But protect_class
> and friends? Nah.
> -- Paul
>
> Hi Paul,
> If I've interpreted TagInfo correctly, worldwide uses of the
> boundary=protected_area tag set are:
> boundary=protected_area                                            73k
> boundary=protected area with protect_class=*        42k
> boundary=protected area with protection_title        35k
>
> So apparently a lot of people are happy to use boundary=protected_area. As
> things stand at the moment, if you don't use it, and/or you want your
> mapping to render, you pretty much have to use boundary=national_park or
> leisure=nature_reserve, which is fine if it's reasonable to describe your
> area as a national_park (which, even outside the US where National Park
> implies a specific federally operated park, can be a stretch) or if it
> really  is open for recreational nature appreciation. But a significant
> number of protected lands are neither. eg, a water company watershed that's
> closed to public access. I think a lot of people seized on
> boundary=protected_area because it's a good, honest, flexible generic
> description of all kinds of protected areas, with no bending of the
> semantics required (though up to now, of course, it didn't get your changes
> rendered)
>
> But the TagInfo numbers show something else, too. A lot of people, like
> you, aren't comfortable with protect_class. Only 42k of the 73k of
> boundary=protected_area have an associated protect_class. But I submit that
> this is OK... If you don't know or aren't interested in the protect_class,
> you can omit it. Someone else can come along later, do the necessary
> research, and complete the description. Also, only 35k added the
> protect_title, which I suppose is also OK, though personally I find it a
> bit sloppy - it shouldn't be asking too much to add "protect_title=
> California State Park", or "Naturschutzgebiet" or whatever. But this
> illustrates the attraction of "boundary=protected_area" - you can use it
> for initial tagging even if you're not sure yet of the detail. Or with just
> the protect_title tag. And expand the tagging later.
>
> But overall, note the 73k uses of boundary=protected_area, of which 42k
> DID use protect_class, and 35k used protect_title. In relatively few years,
> this has become a pretty successful tag set.
>
> Cheers..
> - doug
>
>
>
> _______________________________________________
> 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/20181128/ff37db75/attachment.html>