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 <doughem...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
