Proposal talk:Key:protected area

response 1

Hi Tago,
thank you. It looks more clear and simple and seems to be a good idea.

That enters again into the („old“) discussion about „number or word“. The advantage of numbers is writen in background (in the beginning 2009, there was been only two-three votes for words). This idea will come from time to time.
Even without numbers, you have to read, understand and remember the „complex nature protection“ stuff. And its questionable, if one word will catch the content for everyone in the world – the meaning of „nature reserve“ differs e.g. even between Australia and Europe; I´m afraid too, that content might change a little by time and than you have an established misspelling. I don´t see problems with numbers (or IDs), they look more clear & comfortable. In a global view, word-terms appears for me too a little impolite.

But - osm has anglo-saxon roots and the whole other tags are words, so ... maybe, men has to live therewith (and its possible, to make even tags multilanguage later).

Hi Typoshrub,

can you point me to old discussions about "number or word"?

In "Background" you wrote that numbers are friendlier than foreign names like "Природна". But that's not what I am suggesting. I am suggesting english names as they are used everywhere in OSM. I think that's friendlier than abstract numbers.

The categories defined for the protected area should represent concepts. If it's not possible to express them clearly with a short term like "habitat" then it's probably not a good concept. A good concept also guarantees a stable meaning over time.

I am afraid one of the ideas of using numbers for the categories was to make mappers look up the documented protect classes and get involved in adding stuff to the tables. I think that's expecting too much from numbers. Someone who doesn't want to spend much time on this will find the word Nature Reserve in one of the tables and then he will use protect_code 1 for it, no matter if it has a different meaning in his country or not. Or he ignores that key protect_code ought to be obligatory and just enters tag boundary=protected_area as in practice happens in the majority of cases. Numbers don't solve this problem. There are certainly more efficient forms of quality management. I would suggest to try solving it by means of improved organisation and tools.

With a view on „boundary is a one-dimensional object, whereas an area is two-dimensional“ ... Yes – and with only one tag, the concept is easier to use. The use of boundary was based for highlighting the fact, that protection is more a political decision than based on objects of an area and too because of the boundary-tag national_park and the use for state-borders and - maybe - some technical matters. But at least, I don´t know now, wherefore boundary was been introduced. I´m not sure (I´m out of osm a while) if a doubble-tag was helpfull for tagging complex constructs ... I just tried some things (two classes on one line, scattered areas, iles, ... works mostly with multipolyons), but everything seems to work? Maybe there was been an incorrect use or something changed in osm? So if not: better with just one tag like protected_area=*.

I suppose the use of boundary= stems from the early days of OSM when there were no relations. Without relations boundary= makes much more sense. Unfortunately the same word is now used for a different concept.

But – lets have a discussion – with a view and respect to the programmers. Please make an note/hint to this discussion in some forums like gmane.comp.gis.openstreetmap, openstreetmap.org and post or link to some results. After a discussion, we will see, maybe complement to a better version and the programmers might update the registered database-data? And than some areas hopefully will be rendered.

But before we have to look too for grafical issues like hierarchies of layers, transparency, etc.. e.g. the international p_a´s covers other or I think, some p_a's are less for the common map but for special, thematic maps.

I don't think the priority should be ease of imlementation for programmers. There is certainly no doubt that protected_area= can be implemented. A good and sound design is more important than a fast solution, epecially if it is "only" about the renderer.

Currently I don't have the time to start that discussion. I'll keep you informed and tell you as soon as I dive in.

As mentioned in a p_a-discussion: I wouldn´t admit „public_land“ (there is no reply from the tagger until now).

I agree with you.

Best, --Typoshrub 18:31, 21 November 2012 (UTC)

Best regards, --Tago 14:59, 23 November 2012 (UTC)

Care to merge projects?

Hello there! I think you have some great ideas in your proposal. The way your project describes protection areas is very similar to the proposal (here) I am brainstorming. If you are interested in joining forces please let me know. I believe I was able to get around the issue of nature areas/parks/reserves/etc and add some new things like park networks and protected relationships that you may be interested in. Thanks Viper444 (talk) 08:15, 14 September 2020 (UTC)