Proposal talk:Refugee Site Location 2

From OpenStreetMap Wiki
Jump to navigation Jump to search

The proposed feature place=refugee_site has already been debated and voted on from 30-01-2020 to 17-03-2020. It was then rejected by a narrow margin on the final day of voting. We have since tried to answer to the concerns and comments received, and to adapt and simplify the proposed tag to map refugee site location. We would like to discuss this tag with all interested people again during the Request For Comment phase, open until Friday, April 3rd. Thank you ! Manonv (talk) 13:52, 25 March 2020 (UTC)


Objectives

  • develop a general set of tags which satisfy all the tagging requirements of the many colors and flavors of refugee sites which exist in the world.
  • develop tags which allow one to describe the features of the refugee site element, such as the "operator" (eg.UNHCR) , the type of population (refugee_only/internally_displaced), if the site is formal or informal, the refugee population, etc ..
  • develop tags which allow easy refugee site data extraction from the OpenStreetMap database using Overpass by anyone who wants to display refugee sites on a map

Manonv (talk) 15:11, 3 April 2020 (UTC)


[NO LONGER VALID ANYMORE] Why we choose the key:place instead of key:amenity or key:social facility and why we think it is not recommended to tag the refugee sites as villages or cities?

Refugee and Internal displaced camps are often large populated places where hundreds, thousands or even more (many count more than 50,000 residents, up to almost 1 million for Kutupalong in Bangladesh) people live. Although they are set up as temporary, many of these camps end up staying for years (for instance nearly one-third of Palestinian refugees still live in refugee camps decades after their arrival). In this context we find that the key:place is better suited, instead of the key:amenity or key:social facility that are already partially in use but not suited for this context.

This is also why we recommend using only this key place=refugee_site and not village/city since these sites have a status permanently different to a “regular” populated place (the common legal framework of the country doesn’t apply to it).

Amenity and social facility tags should however still be used in order to map individual facilities within (or outside) the refugee sites like community centres, reception centres, transit centres, food distribution centres, child-friendly spaces or shelters.

Manonv (talk) 18:06, 24 March 2020 (UTC)

In the previous proposal Proposed features/Refugee Site Location at least 6 people who opposed the proposal mentioned the key place=* was not acceptable to them. Comments:
"What about places that are de facto village/town but still administered by UNHCR or another humanitarian organization or governmental agency?"
"...many long-term refugee camps have developed into a village or town, where people live for many year. These permanent settlements should be tagged as place=village or place=town, so if the tag for refugee sites uses the same place=* key, then it is not possible to use both at once."
"A refugee camp or site is more like a landuse=residential area or an amenity=social_facility, so perhaps consider using landuse=refugee_site or amenity=refugee_site, or a subtag of landuse=residential, like residential=refugee_site?" (Talk:Proposed_features/Refugee_Site_Location#Suggestions_for_new_proposal))
I'm disappointed that these concerns are being ignored. Instead, we are told "we recommend using only this key place=refugee_site and not village/city since these sites have a status permanently different to a “regular” populated place (the common legal framework of the country doesn’t apply to it)". That is not how we map places in Openstreetmap. See Good_practice "Don't map your local legislation, if not bound to objects in reality" and Verifiability: we don't map what a country claims to be true, but what is actually real. If a "camp" is a 30 year old settlement with >10,000 residentis, plus shops, clinics, schools, places of worship etc, then it is a place=town, no matter what the local government says. Of course it can also be a refugee_site in a way, so the tag for a refugree site should be something that does not conflict with place=village/town. --Jeisenbe (talk) 23:17, 25 March 2020 (UTC)

Hi Manon, I just read through the proposal (and previous proposal and discussion) and I have to say I do support your proposal to use key:place for refugee sites. A refugee site is not a social facility as such, potentially we could say that it is a social facility if it is an administrated and managed camp, but this is certainly not the case for informal refugee sites because no official help is established there. For me a refugee site is really a location, a place where people come and live where they can after they had to flee their home. Often refugee sites are named in first instance like the closest city or town. Later they could disappear or be really integrated most often as a neighbourhood of that place. The tag could than simply be changed to place=neighbourhood and name=*. This is for example currently the case in Bambari in the Central African Republic. The IDP camp Sangaris does not exist anymore, but there is now IDP side Elevage which is more informal. We're waiting waiting to map it correctly for this proposal to finish. :) --Jorieke (talk) 18:15, 25 March 2020 (UTC)

But why not map it both as a place=neighbourhood or place=suburb of the town, as well as tagging it as a refugee site? While I agree that amenity=social_facility is not appropriate for large site, something in landuse= or a new amenity= tag could be fine: an amenity=university can be huge, as large as a neighbourhood. --Jeisenbe (talk) 23:33, 25 March 2020 (UTC)

[NO LONGER VALID ANYMORE] Why we think the key:place is suitable to map the refugee sites?

According to the wiki defintion "a place tag should exist for every significant human settlements (city, town, suburb, etc.) and also for notable unpopulated, named places [..] the tag can apply for Nodes and Areas"

Manonv (talk) 18:57, 24 March 2020 (UTC)

Yes, a long-term refugee site is going to be a settlement, which can be mapped as place=neighbourhood, place=suburb, place=village or place=town as appropriate, but you want a specific to show that it is also a refugee site. The value of the place tag for settlements depends on: 1) whether the settlement is part of a larger town or city (in that case, use suburb, quarter or neighbourhood), and 2) how significant the settlement is, by population and services available. This determines whether to use hamlet, village, town or city, in increasing size/signficance/services. The tag place=refugree_site does not fit into this scheme. --Jeisenbe (talk) 23:43, 25 March 2020 (UTC)

Why we decided to use the generic term “refugee_site” as the main value ?

By experience we know that it’s not easy for people not working directly in humanitarian organizations or government agencies (inc. local mappers) to differentiate the many different statuses of displaced people (refugees, Internally Displaced Persons (IDP), asylum seekers, and other intermediate situations statuses). In everyday language people usually use the term refugees to talk about all displaced people, including IDPs. That is why we decided to use the generic term “refugee” as the main tag. Let’s not forget that many tags in OSM already don’t have the exact same meaning than what they describe, which is logical because these very definitions might vary according to countries.

The sites themselves also have a variety of status, some are restricted to particular population, some on the contrary have residents of various statuses. Some are formal, and under the authority of an official body (UN agency like the UNHCR, government agency, etc.) and others are informal (like the former “Jungle” in Calais, France, or Moria in Greece currently). It is still relevant to use a dedicated tag for them since they are fundamentally different from their neighbouring “regular” villages or cities.

Manonv (talk) 19:22, 24 March 2020 (UTC)

What tag could we use as subtypes to detail the population living in the camp ?

In order to make a distinction when necessary or when one have enough information about the site’s population. We are suggesting to use refugee_site:for=<internal_displaced or refugee or etc..>

Do you have any other idea ?

Manonv (talk) 19:22, 24 March 2020 (UTC)

informal key

One more thing I realised is that there already exists https://wiki.openstreetmap.org/wiki/Key:informal. Probably some refugee_sites would be tagged with this, and it might be worth it to be explicit if this is encouraged or not. --Øukasz (talk) 07:46, 15 April 2020 (UTC)

I agree Øukasz, but I suggest we explicit this in the future wiki page dedicated to refugee site mapping. Manonv (talk) 10:14, 23 April 2020 (UTC)

Why did we decide to provide an alternative to the proposed feature «boundary=refugee_camp» made back in 2018 ?

In most cases we don’t have the official boundaries of the camp. Even the organizations in charge of the refugee sites don’t usually have them. Sometimes refugee sites are next to a host village, or in urban areas where it’s impossible to clearly separate the camp from the nearby neighborhoods when watching the aerial imagery. As refugee site boundaries can be a very sensitive information in some countries, it is not recommended to map imprecise/unofficial boundaries. This is why we suggested mapping the site itself as a node (if the extent is unclear) or an area instead. When official delineation is available, it is possible to use a boundary tag (we would suggest boundary=refugee_site instead of boundary=refugee_camp out of consistency, but this is not part of this proposed tag).

Manonv (talk) 18:14, 24 March 2020 (UTC)

Yes, boundary makes some kind of legal assumption, and we should be very careful with that! --Jorieke (talk) 18:20, 25 March 2020 (UTC)

What about creating a namespace for refugee_site instead of using place=refugee_site ?

Maybe there is value in creating a namespace for refugee_site instead of place=refugee_site, especially if this tag will be sometimes be added to nodes or areas which have other attributes not directly to being a refugee site, like a city, town, district, building complex, etc. Segregating all refugee_site pertinent information within a "mixed" purpose node/area might be useful when extracting data using overpass.

Example ... refugee_site = yes/formal/informal refugee_site:for = internally_displaced/refugee_only refugee_site:operator = UNHCR/Red Cross/etc. refugee_site:duration = permanent/temporary refugee_site:population = 500,000

--European water (talk) 16:37, 26 March 2020 (UTC)

That's an interesting alternative option ! thank you European water
Jeisenbe what do you think ?
Manonv (talk) 17:14, 30 March 2020 (UTC)
I strongly object to this. In my mind, place=refugee_site was already too high-level tag. Defining an entire new namespace would not be nice for semantic reasons - we should be able to fit the concept of a refugee site into the existing data model. --Øukasz (talk) 10:36, 1 April 2020 (UTC)

--Øukasz (talk) Thanks for your comment. I wanted to make sure that I fully understand your objections. What do you mean by not being nice for semantic reasons ? and why do you think this namespace would be even higher-level than place=refugee_site. Just to be clear, I am not suggesting the namespace be a standalone high level tag set, but rather a namespace with segregated refugee site data attached to an either existing or new amenity, or a place, such as amenity = social_facility - as you suggest, or place = city, etc. .--European water (talk) 10:14, 2 April 2020 (UTC)

Ops, then I think I misunderstood you and conflated a couple of separate ideas. My apologies, I'll try to be clearer this time. Let's take the examples: refugee_site:population = 10,000 and refugee_site:operator = Red Cross. In here, I think it's fine to have the :population and :operator suffixes defined. I think, however, that refugee_site should not be defined not as a top-level tag (which I understood before you were proposing, but now see I misread you), but as a value of an existing tag, such as amenity, or social_facility (social_facility of course being a value of amenity). As my final point, I think refugee_site is not the optimal wording, as it would lead to refugee_site:for=refugees tautology. --Øukasz (talk) 16:42, 3 April 2020 (UTC)

I kind of like this solution. Having two tags on a point in the middle of the area: place=village and refugee_site=yes

But wondering can it work for all contexts?

Some examples of camps:

--Jorieke (talk) 16:15, 3 April 2020 (UTC)

I think Jorieke has a great idea to test the proposal. I think it could be worth it to, before voting, see how well it would work in a list of diverse, established examples. --Øukasz (talk) 16:45, 3 April 2020 (UTC)

Call for suggestion : What other options do we have instead of the key:place?

Manonv (talk) 17:21, 30 March 2020 (UTC)

One quick idea would be...

amenity=social_facility already exists with the explicit purpose of mapping "any place where social services are conducted (...) committed to the pursuit of social justice, to quality of life, and to the development of the full potential of each individual (...)". It also already includes social_facility:for=refugee to designate a facility for "[t]hose who are fleeing from a natural disaster or political crisis and seeking refuge in another country or region". It even already has social_facility=shelter, though this seems to be aimed at a single structure rather than an entire area with multiple structures and therefore not very suitable.

I would thus propose to rely on existing amenity=social_facility and social_facility:for=refugee, but define a new value for social_facility=* such as social_facility=camp or social_facility=refugee_site. The latter would have semantic overlap with social_facility:for=refugee, but is clearer and explicit in its wording, which is nice. Downside of having the value as social_facility=refugee_site is the confusion that will arise if trying to use these tags for internally displaced. I also suggest defining social_facility:for=internally_displaced which would help to achieve the purpose of the original proposal in full scope.

name=*, operator=*, capacity=*, population=* are all already defined and would be useful to provider further details. Also suggesting use of lifecycle prefixes.

For clarity, summary:

New values to be defined via proposal
social_facility=* refugee_site OR camp OR other to be defined
social_facility:for internally_displaced
Existing tags and values to be reused - required
amenity social_facility
social_facility:for refugee
name=*
Existing tags to be reused - optional
operator=*
population=*
capacity=*
lifecycle prefixes

--Øukasz (talk) 10:31, 1 April 2020 (UTC)

Suggestion from a group of emergency mappers

Hello and thank you for this proposal. This comment is on behalf of a group of people working in the field of emergency mapping and dealing often with displaced population mapping. We think the idea of consolidating the tagging system in OSM for these features could be incredibly useful in order to reduce inconsistencies and facilitate the identification, download and upload of data from external parties. This is considered to be extremely useful for other organizations that contribute in mapping this kind of features and would like to make their data more suitable for OSM data model, and vice versa. A few comments that hopefully will be useful:

- Following both the previous and the current proposals, it is very clear why you decided to propose the value refugee_site instead of a more generic displaced_population one. Still, it might be more inclusive and less prone to misunderstanding to recur to a more generic displaced_population or displacement_setting value?

- Could it be of interest to insert a tag related to the temporal nature of the feature? Something that would discriminate whether the camp/settlement is temporary or more permanent. An example could be refugee_site:type=temporary/permanent. According to us, it is also still relevant to keep a tag related to the landuse=* type when dealing with areas. It could be interesting to add a new value to the already existing landuses specifically referring to displacement settings, for example a landuse=refugee_site

- It is clear the proposal is oriented to the overall refugee site and not to the single structures constituting the site. Anyhow, we can share a few comments based on the past mapping experience of the group. Would it be interesting to have a tag similar to refugee_site:for=* but intended for the main type of structures constituting the site (same could be done for the material of the structures)? An example could be refugee_site:structures=shelters/tents/multifunctional/mixed. Tents and shelters can be differentiated according to size, shape, material and formality of the camp/settlement. Of course, when tagging a whole site it is difficult to make such a generalization. In case a new tagging proposal will be opened specifically focused on single structures, we would be very interested in providing more comments.

Some examples that may be interesting for classification and tagging of the features at these links: https://emergency.copernicus.eu/mapping/ems-product-component/EMSR341_02ELBEID_02GRADING_MAP/1 https://emergency.copernicus.eu/mapping/ems-product-component/EMSR341_03RANN_00REFERENCE_MAP/1

Thank you again for this very interesting proposal!

Alternative proposed feature

Key refugee_site for large facilities

The key refugee_site=yes is added to a place tag.

  • place=neighbourhood/suburb/village/town
  • + landuse=residential
  • + refugee_site=yes.

The tag refugee_site=yes will allows to easily add secondary optional information to be able to details the typology of the camps and other valuable information like:

  • + refugee_site:for = internally_displaced/refugee_only/mixed
  • + refugee_site:operator = UNHCR/Red Cross/etc.
  • + refugee_site:duration = permanent/temporary
  • + refugee_site:population = 500,000
  • + refugee_site:structure=shelters/tents/multifunctional/mixed
  • + refugee_site:status=formal/informal

Key Amenity=social_facility for small facilities [a majority agreed that social_facility is not appropriate for large site]

For small facilities (less than 5 buildings) also sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center), that are not exactly what we can call refugee site, use the existing tag:

  • Amenity=social_facility
  • + social_facility=shelter
  • + social_facility:for= internally_displaced/refugee

Manonv (talk) 15:05, 3 April 2020 (UTC)

Manonv, thanks for working on this. However, note that it is incorrect to add place=village and landuse=residential to the same area. A place=village or place=town is mapped as a node, while landuse=residential is mapped as an area (a closed way or a multipolygon relation).
If it is allowed to map sites for refugees or internally-displaced persons as an area, can we clarify if these sites are purely residential? If they include clinics, schools, places of worship, shops and offices (e.g. an NGO office), then the landuse=residential area should exclude those features: a landuse=residential area is supposed to only include areas that are primarily residential. In that case it would be better to map the refugree site as a separate area, which includes both the landuse=residential area and the other features which are part of the refugee site. --Jeisenbe (talk) 00:54, 4 April 2020 (UTC)
A little off topic - Jeisenbe, can you please point me to where it is defined that place=villlage and place=town should be mapped as nodes and not areas? --Øukasz (talk) 07:15, 7 April 2020 (UTC)
Almost all are mapped as nodes. The place=town features which are areas almost all duplicate existing node features, and most were imported (for example, from Tiger in the USA) along with administrative boundaries. See https://wiki.openstreetmap.org/wiki/Key:place#Mapping_populated_places_as_areas. --Jeisenbe (talk) 07:26, 7 April 2020 (UTC)
So Jeisenbe, you mention an old import in US. Fine, it doesn't prevent places to be defined as ways or relations. We have currently > 1,000,000 places mapped as ways and relations in the database. You can have a relation place= having a node member as label place=. The wiki you mention states that it's bad pratice to define an area if the area is not well defined, true, but it's valid for any feature but here the area is well defined. Places and landuse are 2 different objects. --Nospam2005 (talk) 09:23, 7 April 2020 (UTC)
Some common values of place=*, like place=island and place=islet, have a well-defined area and boundary: an island is surrounded by water on all sides, so it's sensible to map this as an area, and there are over 400k of these. Many of the place=* areas are place=plot - there are almost 400k - this tag has some problems with maintainability and verifiability, but it's always an area. And place=square, place=city_block are also mapped as areas. And there are 70k place=locality mapped as areas. That leaves a small minority of settlements (towns, cities, villages) mapped as areas (less than 10%), most of which are also tagged as an administrative boundary in addition, and most of which also are mapped as a node at the center. Mapping settlements as an area is not established, since most named settlements do not have verifiable boundaries. --Jeisenbe (talk) 15:02, 7 April 2020 (UTC)
As already mentioned in another thread, if you don't know the boundary, you simply map it as a node. Why do you want to prevent people knowing the correct boundary to map it properly i.e. with relation? --Nospam2005 (talk) 17:03, 7 April 2020 (UTC)
If you know the boundary and want to map it as a relation, then tag it as type=boundary + boundary=*: such as boundary=administrative + admin_level=*, or if that isn't correct, one of the many other value of boundary=* in use: boundary=political for electoral boundaries, boundary=census for census designated places, boundary=historic for historic boundaries, boundary=local_authority for groups of local communes (France/Belgium), boundary=civil, boundary=urban - lots of options. --Jeisenbe (talk) 07:00, 11 April 2020 (UTC)
Are you serious, really? We are about mapping a refugee site with known boundaries and your answer is to map it not as a refugee site!
A relation with boundary=place, place=refugee_site does the job. No need to reinvent the wheel (with a flat tire^^). --Nospam2005 (talk) 19:30, 17 April 2020 (UTC)

Why we finally decided to go with the amenity tag option

In order to keep track of the histoyr of the exchanges and to explain the different choices made, I would like to add a message from Jeisenbe from the tagging mailing list that explain why we finally decided to go with the amenity tag option:

>>“I agree that, under the current, very broad definition of "amenity=social_facility", a single building which is used as a shelter for refugees could be tagged as "amenity=social_facility", but a large camp would not be appropriate, nor would a huge, permanent area with many buildings which has all the characteristics of a village or town. The problem with just using "refugee_site=*" as the main tag is if it is used for mapping areas, because in this case database users would have to add special handling just for this key. Instead, it would be better to use "amenity=refugee_site" or "landuse=refugee_site" or "man_made=refugree_site", "emergency=refugee_site", or any other standard "key" which is already used for area features.

Explanation: There is no native "area" object in the Openstreetmap database. Instead, to map areas we make a way (a line) which loops back to the first node. This called a "closed way", and it could represent a line (for example, a barrier=fence which loops around a field, or a highway=raceway which is a loop), or also an area. To distinguish between these two options for what a closed way can mean, database users have to look at the tags on the feature, and guess if it is meant to be an area or a line.

For example, the iD editor on openstreetmap.org has a list of keys which are considered to be areas:https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json (documented at https://github.com/osmlab/id-area-keys) This includes "amenity=*", "landuse=*", "place=*", "man_made=", "emergency=", "healthcare=" and many others, but of course it doesn't include "refugee_site=" since this key does not yet exist. […] If you want to add a new key to this list, all of the rendering servers have to reload the database. This process takes all day, so the servers are not reloaded very often. So, if you propose mapping refugee sites as areas and not only as nodes, they should use one of these common area feature keys, that database users will be able to start showing these features sooner and more easily.<<

Manonv (talk) 10:43, 23 April 2020 (UTC)

Using abandoned:amenity=refugee_site - replace the main tag

The text currently suggest that you can add the tag "abandoned:amenity=refugee_site":

to be added if the refugee site is no longer in use - optional - wiki

However, it should be clarified that you need to remove the tag amenity=refugree_site and replace it with the tag abandoned:amenity=refugee_site - don't add both tags to the same node or area. --Jeisenbe (talk) 06:41, 11 April 2020 (UTC)

Looking at this, I have one more suggestion: shall the proposal also recommend the was: prefix, as well as the abandoned: one? This would be more suitable for the situations when a site becomes a "regular" village or town. Another way to think about it would be that if an NGO or a government camp management agency withdraws but life in the site goes on, the site doesn't become abandoned, but rather is not a refugee site anymore. --Øukasz (talk) 10:45, 13 April 2020 (UTC)
Good hint Øukasz. Jeisenbe, it shouldn't be in that table, right, but it's obvious that we never have <life_prefix>:<key> and <key> on the same object. --Nospam2005 (talk) 07:17, 14 April 2020 (UTC)
Thanks for the note, in order to be consensual and focus on the essentials, I erased it from the proposal. but definitely it will be good to add it to the wiki data model for refugee site mapping.
If a particular location loses its refugee site status (e.g. site management pulls out and the place becomes a regular, self-sustaining village or town) then it could be changed from amenity=refugee_site to was:amenity=refugee_site.
If the refugee_site is abandoned and the population left then it could be changed from from amenity=refugee_site to abandoned:amenity=refugee_site.
Manonv (talk) 15:04, 17 April 2020 (UTC)

summary for the rationale

The rationale is long, very long, too long, couldn't you be more concise so that the main argument comes out instead of being drowned out? ? Marc marc (talk) 14:22, 17 April 2020 (UTC)

Right, just done it ! Manonv (talk) 14:30, 17 April 2020 (UTC)

experience with recently rejected proposals

experience with recently unsuccessful proposals would be very useful in improving the chances of your proposal being accepted. Proposals generally fail for the following reasons:

  • don't explain clearly why the existing tags are bad. here in this case why a camp of 4 buildings is currently mapped with amenity=social_facility but a camp of 5 buildings would require a new value while the size can be described differently (population, capacity, beds or with the surface of the polygon)
  • too long, if a contributor has to spend 1 hour to understand what you mean, it's not clear.

it is necessary to be able to understand a proposal even without knowing all the abbreviations it contains, no need to explain that humanitarian work is humanitarian, etc, and in this sense, the details should come out or go at the bottom of the page in the "advanced" section.

  • contain inconsistencies, e.g. additional tag abandoned:amenity=refugee_site for amenity=refugee_site. but it is not an additional tag
  • contain controversial advices like adding the source tag on the object instead of the changeet. contain a advice to add a landuse on the same object as the camp, while a big camp could have several landuse (a residential part, roads, a vegetable garden, ...). still advice to add the place=* tag anyway as the previous proposal showed the opposition of part of the community to consider a refugee camp as something falling within the use of the place=* key which describes administrative and geographical locations. drop/clean that, those tags already exist, no need to inclure all existing tags that are not specific to your proposal.
  • forget to include the link to the tagged discussion, allowing ultra-motivated people to read what was said there.

in summary : be consensual, focus on the essentials Marc marc (talk) 14:47, 17 April 2020 (UTC)

Thanks Marc marc, I will try to keep it consensual and focus on the essentials. It's true that we have extended the discussions on additional tags related to the proposal, this may not be the right time or place and it may indeed block the vote again, but it's also an opportunity to discuss this general harmonization of the way to map refugee site on OSM ! I'm happy to see input from other contributors because a sustainable approach that considers as many use cases as possible is necessary ! Manonv (talk) 15:18, 17 April 2020 (UTC)
I think the proposal looks much stronger now. I agree with Marc marc that what's missing now is a clear distinction between this proposed tag and the already existing social_facility=shelter. I also think that drawing the line between 4 and 5 buildings seems arbitrary and we need a better definition to separate the two.
Separately from this, perhaps it would be worth to launch parallel proposal for the :for suffix with allowed values such as internally_displaced and temporary_evacuee. --Øukasz (talk) 19:41, 18 April 2020 (UTC)


distinction between this proposed tag and the already existing social_facility=shelter

In order to clarify the distinction between this proposed tag and the already existing social_facility=shelter, I suggest to add this paragraph in the Rational Chapter :
There is already a tag social_facility=shelter to map a single building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.
But this tag is not suitable to map refugee camps that are human settlements/ populated places where hundreds or thousands people live. That’s why we propose to create a new value for the amenity tag : amenity=refugee_site, to map human settlement where refugees can find protection.
What do you think ?
Manonv (talk) 10:31, 20 April 2020 (UTC)
That's an improvement. However, it's still not making a clear distinction between when to use social_facility and when to use amenity=refugee_site. I think it would be better to suggest that amenity=refugee_site should be used for any facilty that is dedicated to housing refugees, and say that amenity=social_facility could be used just for facilites that provide services, but do not provide full-time residences for refugrees and evacuees. Personally, I think too many different things are currently lumped together under amenity=social_facility, so it's fine to separate out refugee residential sites. --Jeisenbe (talk) 12:33, 20 April 2020 (UTC)
Agreed with above that it is some clarification, but the distinction is not unambiguous. To be precise, from this paragraph we know that a small group of buildings is a social_facility=shelter, and settlement where hundreds of people live is amenity=refugee_site. What about a facility with 199 people? Or 99 people, all in 2 (admittedly large) buildings? I think these are cases that will appear in the real world and clarity on which of these categories would be helpful. I have an intuition - perhaps wrong - that instinctively at least some of us may be thinking of this distinction in terms of "small, managed centres in the global north with relatively high standards" vs "large camps in the global south with relatively low standards". In other terms - are we thinking about the distinction in terms of a) number of physical structures that make up the amenity, b) number of individuals that reside in the amenity, c) appearance, genesis, other features? A) and b) are easy to set an (arbitrary and never perfect) threshold for, c) requires clearer definitions. --Øukasz (talk) 14:35, 20 April 2020 (UTC)
Is it really necessary to set up a precise rule? are the tags in OSM defined to this level of details ? can't we leave some room for interpretation according to the definition above ? I don't have more inputs to defined a clear and exact distinction. I have already gave my argument : distinction is between a human settlement (and I agree with Jeisenbe that gather several different facilities, not only housing) and a single facility. Some accommodation center for refugee host more than 199 people for sure, but for me it's still a social_facility=shelter because it's not named a refugee camp or a refugee settlement but an accommodation center, people live in one building, there is no other human settlement related services or infrastructures so it's a shelter not a refugee site. I'm not against to precise the distinction but my side I have no more suggestion. Manonv (talk) 16:51, 20 April 2020 (UTC)
Re: "other human settlement related services or infrastructure" - you can make this part of the definition, if you think that both tags are needed. Yes, for a proposal it is important to define when a tag should be used instead of another, similar tag. My preference is to discourage the use of social_facility=shelter for all types of refugree sites: this avoids any problems with the definition. --Jeisenbe (talk) 22:41, 20 April 2020 (UTC)
New proposed definition :
There is already a tag social_facility=shelter to map a single building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees which are residential facilities for refugees. But this tag is not suitable to map refugee camps that are human settlements/ populated places that gather many different facilities, not only residential, but also outreach, NGO or government offices, warehouses, Water Hygiene and Sanitation facilities and also health and education facilities along with regular human settlement related services and infrastructures. That’s why we propose to create a new value for the amenity tag : amenity=refugee_site, to map human settlement gathering diverse facilities that provides services to refugee not only housing.
What do you think ? I think it's the last blocking point we could launch the vote if people agree with that ! Manonv (talk) 16:53, 21 April 2020 (UTC)
I do think that's better, with one tiny provision that in your paragraph above "(...) suitable to map refugee camps that are (...)" it should read refugee sites rather than refugee camps - otherwise, our new tag should have value refugee_camp. Additionally, what do we think about saying that amenity=refugee_site is meant to be used for sites broadly similar to https://en.wikipedia.org/wiki/Refugee_camp? Does that match your concept?
There is one more "blocking point" I think, which is that currently the proposal is recommending use of refugee_site:for=internally_displaced and refugee_site:for=temporary_evacuee, etc., without defining those. I think someone raised this as a specific objection in the previous vote. --Øukasz (talk) 09:22, 22 April 2020 (UTC)
Thank you Øukasz, It's an excellent idea to add this link, the definition match exactly the concept !
For the last blocking point you mentioned, I think it's better to postpone this one to an other vote, once the main tag for refugee site is validated. So I will erase it from the page for the moment.Manonv (talk) 09:12, 23 April 2020 (UTC)
I think that's fair, easier to break the approval process into smaller chunks. Hope the new values are defined and approved. Just a note - there are the 'displaced' and 'refugee' values already, whose definitions do not quite match the humanitarian world ones. They were added a while ago: https://wiki.openstreetmap.org/w/index.php?title=Key:social_facility:for&action=history. I've put a question to the contributor to understand where the definitions came from: https://wiki.openstreetmap.org/wiki/User_talk:GOwin. Good luck with the vote!
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Refugee_Site_Location_2&oldid=2516969"