Proposal talk:Refugee Camp Boundaries
let's try to validate the proposed features !
I’m working for CartONG and we were asked by the UNHCR to improve referencing of refugee site map in OSM for the UNHCR Site Maping platform. As you know, many settlements are mapped in OSM but tagging is applied inconsistently. This make it quite difficult for an automatic script to localize them. As we are going to check one by one every settlement operated by UNHCR, we thought it would be a great opportunity to try to standardize the way we tag and identify the refugee sites.
We have some suggestions for those tagging options that we would like to discuss with you, and maybe try to have a validation of the OSM community !
- We suggested to use site_level=* instead of admin_level=* in order to limit confusion with administrative feature, but we are not sure if this will impact the default rendering, in this case it might not be really recommended. UNHCR use 0 for site boundaries, 1 for first admin division (Zones), 2 for second admin division (Blocs) and 3 for third admin division. It may be a good option to match with that?
- In most case, we do not have the official boundary of the camp (not even the UNHCR have it!) so we are not very keen to draw imprecise boundary as it can be a very sensitive information in some countries. We prefer other options such as to add a node in the center of the camp associated to place=refugee_camp for instance and only add the residential landuse. What will you do in that case?
- Do we really need to add refugee=yes, we may not be targeting a particular vulnerable population?
place
You propose a new place value, I suggest it becomes a property, because refugee camps come in all sizes and some might be proper cities or towns, so I see potential for conflict with a new place tag.—Dieterdreist (talk) 13:49, 26 May 2018 (UTC)
Not so keen to use boundary tag. Using boundary=administrative makes the search for the real administrative boundary more complex because we should add a filter. An area with existing tag could be used instead.
Moreover in some situation the boundaries couldn't be known. Take a look at Baidoa https://www.openstreetmap.org/#map=14/3.1152/43.6615 where many IDP camps are inside the city. There we have used amenity=social_facility and social_facility=shelter with the possible further specification social_facility:for=displaced or social_facility:for=migrant These tags seems to fit the needs and could be used also with the nodes, when the camps are tiny or not well defined in their border. --UNGSC-DTLM-Ale Zena (talk) 09:52, 23 May 2019 (UTC)
informal
Also have a look at the key informal=*, could help distinguishing formal from informal camps.—Dieterdreist (talk) 13:49, 26 May 2018 (UTC)
admin_level
Currently there is no explicit definition yet how to apply (which) admin_level / what it means with the new boundary value. —Dieterdreist (talk) 13:52, 26 May 2018 (UTC)
promote admin_level for administrative only
I agree with a boundary=<not administrative> because boundary=administrative is wrong when it isn't a administrative boundary but it's the same issue with admin_level, using it for any not-administrative boundary is incoherent Marc marc (talk) 16:01, 13 June 2019 (UTC)
- +1, more over no need to create another scheme: see Refugee Site Location#place and boundary. KISS
- If you want a "hierarchy", first it sounds strange to me: are refugee camps split into smaller administrative boundaries? No, they are not.
- Then you want to describe the importance of the settlement/camp.
- This can be described with the key refugee_site=*, see Refugee_Site_Location#refugee_site not refugee_site:type. --Nospam2005 (talk) 20:40, 9 February 2020 (UTC)