Proposal:Refugee Camp Boundaries

From OpenStreetMap Wiki
Jump to navigation Jump to search
Refugee Camp Boundaries
Proposal status: Abandoned (inactive)
Proposed by: Kateregga1
Tagging: boundary=refugee_camp
Applies to: relation
Definition: Refugee camp/settlement boundary tagging
Statistics:

Draft started: 2018-03-14
RFC start: 2018-05-24

Introduction

Current Guidance for IDP/refugee camps

Current guidance for administrative levels within the camp are recorded at 2 levels (According to the Refugee Mapping wiki), following traditional administrative boundary tagging: For level 1 (Camp sectors or modules)

key value
place suburb
admin_level 8
boundary administrative
refugee yes

For level 2 (Camp blocks or communities)

key value
place neighbourhood
admin_level 9
boundary administrative
refugee yes

At this moment, refugee camp/settlement tagging is applied inconsistently, and the use of the same boundaries and admin_levels as are used at the national and subnational level creates issues in a number of situations, including being hard to explain and thus limiting uptake among local government officials and responders. Unclarity on which set of boundaries take precedence, and how these affect accountability in regards to population serve as indicators that this system needs changing to reflect the growing need for consistently representing refugees and displaced persons on a map.

Options to distinguish regular administrative boundaries from refugee camps:

  1. Use regular `boundary=administrative`, but use a different hierarchical structure for `admin_level` (for example, `admin_level=7_rc`). Disadvantage: not in use currently, adherence to numeric values seems pretty unanimous for `admin_level`.
  2. (https://taginfo.openstreetmap.org/keys/admin_level#values).
  3. Use regular `admin_level` values and `boundary=administrative`, only amended with `refugee=yes`. This seems to be used on several other camps right now.
  4. Use `admin_level` as normal, but introduce a new value for boundary, in effect allowing a parallel hierarchy of admin_levels specific to refugee camps/settlements [1]. Used for example on national parks, postal codes, voting districts and other boundaries that may intersect with administrative boundaries at various levels (`boundary=national_park`). Proposal for the value to use: `boundary=refugee_camp`.

OSM Boundary Resources

Proposal

  1. We are proposing to go with option #3: “Use `admin_level` as normal, but introduce a new value for boundary, in effect allowing a parallel hierarchy of admin_levels specific to refugee camps/settlements.”
  1. What value should we use on `boundary`? We propose to use the key/value `boundary=refugee_camp` for all types of refugee camps, including IDPs. For backwards compatibility, these boundaries should als be tagged with `refugee=yes`. While using `refugee_camp` does not explicitly reference IDPs, it meets the criteria of being clear, concise, intuitive, and easy to remember.
  1. This allows for:
    1. Boundaries of refugee camps/settlements to be defined independent/in parallel to the regular administrative boundaries of a country;
    2. Quick identification of mapped refugee camps, for use in portals such as https://ugandarefugees.org/ and http://maps.unhcr.org/apps/cm/index.html?camp=UGAs027216 (which CartoNG is working on to improve with better analysis of OSM data);
    3. Visualization/analysis of the coverage of refugee camps versus host communities and already inhabited land.
  1. In addition to these, the `Refugee Camp Mapping` wiki mentions camp boundaries may be tagged with `landuse=residential` as well. We think this should remain recommended. This helps identify camps in (early) stages of refugee crises where boundaries may be fluid, dynamic, de facto rather than official, and evolving.

Rationale

  • Refugee and IDP camps and settlements (both official and informal) may exist across national and subnational administrative boundaries. For example, Rhino camp in Uganda spans multiple counties and subcounties in Arua district, while Bidibidi spans multiple counties and subcounties in Yumbe district.
  • The potential downside is that these boundaries will not be rendered on the regular OSM basemap (yet). However, a principle in OSM is not to tag for rendering effecs (only). Additional tagging with `landuse=residential` can alleviate this to a certain extent.
  • Using a distinct value for `boundary` allows responding organizations to easily identify camp outlines and facilities, and set up exports specifically for these responders.

Examples

Tagging

Formal Camps/Settlements (polygons/relations)

key value required? taginfo?
boundary refugee_camp yes taginfo
admin_level [2-11] yes wiki
name <sting> yes wiki
refugee yes yes taginfo
landuse residential temporary wiki
population <number, estimated population> optional wiki
capacity <number, planned max population> optional wiki
start_date <date, establishment> optional wiki
operator <name of operator> optional wiki
operator:type <ngo,community,government,intergovernmental_organization> optional wiki
name:en <string> optional wiki
official_name <string> optional wiki
loc_name <string>, local name optional wiki

Additionally on relations:

element_type key value required? taginfo?
relation type boundary yes wiki
relation_member role subarea if child wiki
way_member role inner optional wiki
way_member role outer optional wiki
node_member role admin_centre optional wiki

Informal camps - No official boundary (polygons)

key values required?
refugee yes yes
landuse residential yes
place refugee_camp yes
population <number, estimated population> optional
capacity <number, estimated or planned max population> optional
start_date <data, establishment> optional
name <string> yes
name:en <string> optional
loc_name <string>, local name optional

Application in Uganda, OPM/UNHCR Settlement Structure Arua

Imvepi Settlement Rhino Camp
01 Settlement 01 Settlement
02 Zone 02 Zone
03 Point 03 Village
04 Village/Block/Tank 04 Block/Tank

Proposed Uganda “admin_level” Adaptation

element_type key value settlement_level query
relation admin_level 2 settlement Link
relation admin_level 3 zone Link
relation admin_level 4 village/point Link
relation admin_level 5 villages/block/tank Link

Camp boundaries - Applied in Uganda

Main Settlement

key values required?
refugee yes yes
admin_level 2 yes
boundary refugee_camp yes
name <string> yes
type boundary if relation
operator <string> optional
operator:type <ngo, community, government> if operator=*
population <number, estimated population> optional
capacity <number, estimated or planned max population> optional
start_date <data, establishment> optional

Settlement Subareas

Zones

key values required?
refugee yes yes
admin_level 3 yes
boundary refugee_camp yes
name yes
type boundary if relation

Points/Villages

key values required?
refugee yes yes
admin_level 4 yes
boundary refugee_camp yes
name <string> yes
type boundary if relation

Blocks/Tanks/Villages

key values required?
refugee yes yes
admin_level 5 yes
boundary refugee_camp yes
name <string> yes
type boundary if relation

Rendering

Refugee Camp Boundaries - Uganda (Query: http://overpass-turbo.eu/s/wPc☂)

Settlements - admin_level=2 (Query: http://overpass-turbo.eu/s/x4e☂)

Zones - admin_level=3 (Query: http://overpass-turbo.eu/s/wOh☂)

Villages/Points - admin_level=4 (Query: http://overpass-turbo.eu/s/wOi☂)

Blocks/Tanks/Villages - admin_level=5 (Query: http://overpass-turbo.eu/s/wOj☂)

Features/Pages affected

External discussions

Comments

Please comment on the discussion page.

  1. ↑ As other values for `boundary` do: https://taginfo.openstreetmap.org/keys/boundary#values
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Refugee_Camp_Boundaries&oldid=2516959"