[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

Paul Johnson baloo at ursamundi.org
Wed Nov 28 23:22:00 UTC 2018

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>

More information about the Tagging mailing list