On Sun, 28 Jul 2019 at 02:36, Paul Johnson <[email protected]> wrote:
> I'm on board with a state park specific tag. I find protect class to be a > clunky answer and not entirely humanly intuitive compared to something like > leisure=state_park > +1 I have no objections to protect_class as supplemental information that data consumers can make use of as they wish (including ignoring it). I have an intense dislike of numbers being used for anything other than numeric values because they are not amenable to human inspection. Sure, editors can unobfuscate things by using an internal lookup table, but that isn't a complete solution. Compare an overpass-turbo query for leisure=state_park and for protect_class=21. Use the query tool of standard carto and ask yourself how easy it would be to guess what is meant by leisure=state_park versus protect_class=21. Look at the raw tags in the editor (something I frequently do, for one reason or another) and see if leisure=state_park makes more or less sense than protect_class=21. But if we insist that protect_class=21 is a sensible solution, then so is replacing all existing top=level tags with things like object=Q1234 and object=Q9876. Well, that doesn't cope with values, so we'd have to replace building=house with object=Q1234 + Q1234=Q9876. Obviously (I hope) this is not a sensible solution, but it is merely a logical extension of the thinking that gives us protect_class=21 as a top-level tag. -- Paul
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
