Talk:Colorado State Lands import
Initial suggestions
Where you have initials like "SAA" for operator=State Administering Agency or SFU for operator=State Forestry Unit I think you want to substitute in for these strings the actual name(s) of the Agency or Unit. Doing it as you propose seems like it is causing a loss of data, as we don't know which SAA or SFU is being denoted here. Same for SP and STL: WHICH state park? WHICH state trust land? In my state, a wildlife area adjacent to / part of a state park might be called a "unit" of that state park, or a "wilderness unit" if it is Class 1b wilderness (and so on). But they all have names as they are all associated with a specific [state park, state forestry unit, state trust land...].
There are absolutely not "fine lines between" landuse=recreation_ground, leisure=park and boundary=protected_area. I've spent much of the last decade outlining [with others, in wiki, at conferences, in email...] these differences. While I agree there are subtle aspects not readily apparant to the unitiated, and for that I apologize even though it's no fault of my own, but rather early tagging in OSM and its legacies continuing into the present and future, these are three quite distinct tags. There are others. Others in OSM can help you come to agreement about what might be best tagging practices. Often this can come down to a mapping from something that's the equivalent to the values of what might be in protection_title=* and collecting those into groups with the same tags (or very close).
For inholdings that are inner members of multipolygons: I suppose you could name these, if you knew, for example, the name of the owner as separate from the outer "state" (public) lands' name. We have a few of those around San Mateo County in California, where the last name of the property holder is added as the name of the inner member inside of I think it is Butano State Park. But not very often.
I really like your "I'll go get the correct data on my next field trip..." approach! It shows dedication to a continuing / ongoing effort on your part to both improve and update data going forward. That's great. Stevea (talk) 03:50, 28 April 2024 (UTC)