On 11/26/18 17:00, Mateusz Konieczny wrote: >> and I fail to see how much more >> difficult it is to tag "boundary=protected area" and "protect_class=24" > > Because "24" is a completely random code, unlike boundary=aboriginal_lands
And on 11/26/18 17:00, Frederick Ramm wrote: >We generally *try* and make our data human-readable. If archaeologists >dig up an old planet file in 1000 years, then finding a tag >boundary=aboriginal_lands is more useful to them than protect_class=24. (Thanks for the levity, Frederick. And I take the point, but see below) Mateusz and Frederick, 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. They even both have look-up tables by country. And the class numbers are not arbitrary, Mateusz, - they map to IUCN categories. But seriously, how many aboriginal lands do you think a mapper would have to tag before they remember "protect_class=24"? 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,.. (to borrow from the proposal page), or perhaps just "aboriginal_lands" as a default. The protect_class groups the area-types of broadly similar purpose and/or level of protection out of what could be hundreds of variously titled protected-area-types around the world. Future archaeologists should be pleased. But although I don't buy your "numbers are bad" argument - nevertheless, having read the other comments on this topic I am almost persuaded that protected_area is not really appropriate to describe what is essentially a sovereign country. It might even be considered demeaning. Something based on administrative boundaries (which I don't have much experience of) might be better. I still think introducing another top-level "boundary= aboriginal_lands" tag is wrong. If we're not careful, boundary= will wind up like amenity=* - too many darned fragmented values under one tag. But I'm dropping out of this particular discussion (... and there was much rejoicing.... :-)) What I'm really interested in is the use of boundary=protected_area to accurately describe Nature-protected-areas and Resources-protected-areas. The "numbers are bad" assertion worries me and prompts a broader question: if this is "policy", does it mean that boundary=protected_area, and protect_class=* tags are doomed in OSM? Have we found the covert reason why carto still doesn't render it, despite the fact that it could be rendered (at least initially) exactly like boundary=national_park? And despite the fact that there are 70,000 uses around the planet? Could we be excused for suspecting that there is an "OSM Establishment" who would like to see it deprecated and go away? OK, maybe I have a nasty suspicious mind - but I can't help wondering. If true, could someone please come clean and just tell us to stop using it (and tell us what else to use)? I'm also wondering (an even broader question) at the justification for making a decision like this (the approval of boundary=aboriginal_lands) on the basis of 20 or so votes (so far, hopefully more to come) mostly from involved and passionate supporters of the proposal out of the hundreds of thousands in the OSM community. Where are the OSM'ers who originally created the boundary=protected_area proposal and got it approved. Have they voted? And likewise for all the mappers responsible for the 70,000 uses? Have we had any involvement from South American mappers, where there seem to be a lot of protect_class=24 uses? This is clearly a question for another time (and mailing list) and it may have come up before, but it IMHO we need a more broadly based way of deciding things like this. Cheers.. _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
