Proposal talk:Refugee Site Location

[For better fellow up of the proposed feature, I will copy the messages/comments received in the tagginglist]

03/02/2020 timmcnamara said:

Is there any knowledge that we could draw about standards from other agencies writing in this area? Perhaps UN OCHA or UNHCR?

As you can see in the proposal, we have indeed based our proposal on UNHCR “standards”, but we are open to discuss other organization’s standards to find a proposal that fits well all the characteristics of refugee sites.

30/01/2020 Mateusz Konieczny said:

What about long term refugee camps that turn into villages or towns? How one should tag such places?

We suggest: When the refugee site is under operation of UNHCR or another humanitarian organization or governmental agency , we can use the tag place=refugee_site, In case the site is no longer under the management of any organization but there are still people (refugees and other population) living there for the long term, then we can use the tag place=town or place=village.

Concerning the refugee site locations UNHCR wants to integrate in OSM, all of them are still under operation so they should be tagged as place=refugee_site.

What about places that are de facto village/town but still administered by UNHCR or another humanitarian organization or governmental agency? Even if nothig like this exists now it may be nice to avoid this problem Mateusz Konieczny (talk)

If the area is still under operation of UNHCR or another organization or governmental agency dedicated to displaced people, the place is still a “refugee site” even if long-term.

Also, from proposal " Should not apply to area when official camp boundaries are not available." Where area is clear it is perfectly fine to map it, even if there is no available official data.

Boundaries in OSM (as defined in the [[1]]: ) refer to administrative areas, not just to delineation of a place (for instance the boundary of a city doesn’t match its residential area). It is in particular the case for refugees sites that are next to a host village, or in urban areas where it’s impossible to separate clearly the camp from the nearby neighborhoods when watching the aerial imagery. We therefore recommend to not use the tag unless there are either official limits to import, or local knowledge from people in the field.

"or local knowledge from people in the field" - yes, this kind is needed (even to import data! you need to verify quality). But still, my main problem here is that this kind of claim may be misleading, OSM uses official data sometimes but it is not overriding reality Mateusz Konieczny (talk) 23:43, 10 February 2020 (UTC)

Cf. our answer below on Nospam2005’s question.

Interesting proposal, thank you for this.

I have a few very quick points off the top of my head:

1. You are proposing to subdivide place=refugee_site into refugee_site:type={refugee_settlement, refugee_camp, IDP_settelemnt, IDP_camp}. The typo in 'IDP_settelemnt' notwithstanding, I think it is not correct to have and IDP_settlement and IDP_camp as a subtype of a refugee site. Perhaps displaced_site would be more accurate?

It is true that Internally Displaced Person and Refugee are two different statuses. By experience we know that it’s not easy for people not working directly in humanitarian or development organizations (inc. local mappers) to differentiate those two statuses. In everyday language people usually use the term refugees to talk about all displaced people, including IDPs. Also, some sites may include the 2 different categories of people in the same location.

That is why we decided to use the generic term “refugee” as the main tag and to propose a subtype IDP or refugee to make a distinction when necessary or when one have enough information about the site’s population. Let’s not forget 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.

We were suggesting to use UNHCR current categorization of refugee site {refugee_settlement, refugee_camp, IDP_settlement, IDP_camp}, but based on the comments we received, we will amend the proposal to simplify it and modify subtype Refugee_site:for=refugee or refugee_site:for=IDP when information about the site’s population is known.

1. On point "Why did we choose the key:place instead of key:amenity or key:social facility?" you justify "Some even end up turning into actual cities." If a place is an actual city, I think the place=city would be adequate?

Correct (cf. previous comment)

In that case, I think we will have a problem where certain places would both qualify as refugee/IDP camp/settlement AND as a village/town/city. I would prefer to see the four proposed tags (refugee_settlement, refugee_camp, IDP_settlement, IDP_camp) as values of the social_facility key. My argument for that is actually the same that you use here against this: "Those places are theoretically temporary, but in practice, these camps and the population living there often end up staying for many years. Some even end up turning into actual cities." Let's allow features to be tagged as both a town or city AND as a refugee/IDP camp/settlement at the same time. --Øukasz (talk) 14:58, 21 February 2020 (UTC)

Yes, sure, when the refugee site is very close or even inside a city/village features can be tagged as both a place=town/village AND place=refugee_site at the same time.

1. Re your point "Under the “Do No Harm” principle, it should be strictly forbidden to use the tag refugee=yes for individual buildings" - while I agree in principle, I wonder if there is mechanism within OSM to "strictly forbid" certain tag?

It is true it is not really possible to “forbid” something, and we will not do a global review/edition of all the existing refugee=yes tags if not in our areas of interest. We could rephrase the proposal “it is strongly not recommended”.

Øukasz (talk) 10:07, 30 January 2020 (UTC)

What is the defintion of a refugee site, IDP_settlement and IDP_camp?

IDP = internally displaced person(s) persons or groups of persons who have been forced or obliged to flee or to leave their homes or places of habitual residence, in particular as a result of or in order to avoid the effects of armed conflict, situations of generalized violence, violations of human rights or natural or human-made disasters, and who have not crossed an internationally recognized state border." OCHA Guiding Principles on Internal Displacement

The proposal needs to clear define what is and what is not a refugee site or camp. Are there only temporarily (3 to 12 month) facilities, or can we map Palestinian "refugee camps" which have been in the same place for generations and have grown into towns.

A refugee site is a place that hosts refugees and/or IDP population and that is under the mandate of UNHCR or another organization (other NGO, government agency, etc.). It can be a temporary site or a long term site.

And what does the abbreviation IDP mean?

Internally Displaced Person

--Jeisenbe (talk) 21:58, 30 January 2020 (UTC)

Daniel FOLKERINGA (DF45) 04/02/2020 said

Bien prévoir qu'il n'y a pas que des réfugiés au sens ONU. Il faudrait peut-être prévoir cela dans les refugee_type. Je pense aux victimes d'inondations ou aux déplacés de Fukushima. Mais peut-être sont-ils vus au sens d'IDP également ?

J'ai été sidéré d'apprendre que lorsqu'un réfugié entre dans un camp de l'ONU, il y reste en moyenne ... 16 ans ! Donc : oui, le tag place=refugee_site a un sens.

place and boundary

I don't agree with: "The tag boundary=refugee_camp should apply only when the official boundaries of the camp are known or when the contributor has good knowledge from the field.". There is no reason not to use a more generic shema:

Use the tag place=refugee_site on a node (when the boundary is unknown/fuzzy) or on a relation type=boundary boundary=place place=refugee_site when it's known.

As Mateusz Konieczny mentioned, a de facto not an offcial boundary is sufficient to map the boundary. If you really want to know the status, add a tag like status=de_facto. You have already drawn buildings from imagery, not only from the cadastre, right? --Nospam2005 (talk) 19:59, 9 February 2020 (UTC)

We do not recommend adding boundaries when they are neither official nor provided by a local source. But if the information is important for a contributor who knows the boundary of the refugee site, they can add it to OSM as you mentioned, we recommend to use  : Boundary=refugee_site In this case it would be indeed recommended to add status information. Status=de_facto is not in use in other fields so we don’t recommend creating a tag just for this. There is an option with official_status=official/unofficial ; or use source=local knowledge or source=official What would you recommend? Or do you have any other suggestion?

refugee_site, not refugee_site:type

KISS, as you want to refine a place=refugee_site, use the key refugee_site=* to refine it!

refugee_site=refugee_settlement or refugee_site=IDP_settlement or refugee_site=IDP_camp or refugee_site=refugee_camp.

":type" doesn't bring any added value, does it? --Nospam2005 (talk) 20:33, 9 February 2020 (UTC)

+1 That's a good idea.--Luther (talk) 01:05, 10 February 2020 (UTC)

Thanks, it’s a good point. We have decided to simplify the subtype, cf. previous comment. The distinction between Settlement and Camp was inspired by UNHCR’s categorization, but it turns out it is actually evolving on their side too (and is not so clear) so we have dropped it. We propose to only make a distinction between Refugee and IDP, Cf. previous comment.

Refugee vs IDP

It is not clear the difference between Refugee and IDP. I understand that "IDP" should be "internally-displaced_persons" (could be "internally_displaced" since we don't use acronyms in Openstreetmap tags), but aren't these still a type of refugee? Are you saying that refugee_settlement:for=refugee should only be used when the people are from another country? This needs to be clearly defined. All new tags in proposals need to have clear descriptions. --Jeisenbe (talk) 22:04, 2 March 2020 (UTC)

We are suggesting to use forcibly displaced people legal status, as explained above: “Internally Displaced Person and Refugee are two different statuses. By experience we know that it’s not easy for people not working directly in humanitarian or development organizations (inc. local mappers) to differentiate those two 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 and to propose a subtype IDP or refugee to make a distinction when necessary or when one have enough information about the site’s population“

operational_status and official_status

There is also mention of additional tags "operational_status" and "official_status=unofficial" which are undefined.

The second, official_status, had a proposal but that one was quite different (https://wiki.openstreetmap.org/wiki/Proposed_features/Official_status)

And operational_status=* has no wiki page, and this proposal does not define it

All new tags need to have a complete description so that mappers will have an objective and clear way to use them. --Jeisenbe (talk) 22:13, 2 March 2020 (UTC)

Thank you for bringing this up, very valid point! I would suggest not to have these tags in the proposal at all, but rather use what is already established:

* instead of official_status use operator=* - if the operator is the UN, a national agency, or an NGO then this would imply that the site is 'official'. If there is no operator, it implies the site is 'unofficial'

* instead of operational_status, use the lifecycle prefixes

--Øukasz (talk) 14:46, 11 March 2020 (UTC)

“operational_status” is not an approved tag but it is largely in use, more than 160 000 uses everywhere in the word : https://taginfo.openstreetmap.org/keys/operational_status that is why we suggested it’s use as optional and only in addition to the main tag place=refugee_site

But we agree with Øukasz we can suggest to use lifecycle prefixes

We also agree we shouldn’t use the “official_status” tag, it was a suggestion to one of the previous comments. Instead we could use only a “source” tag and then specify if the source is official or not, or from field knowledge for instance, We also already suggested to use the "operator" and "operator:type" in addition.

Great, thank you for considering these --Øukasz (talk) 13:33, 17 March 2020 (UTC)

Suited for global north also?

Hey,

I like this proposal because it is an effort to overcome inconsistency. Quick question: The images shown present refugee camps presumably in the global south. But is is Tag also suited for Europe like https://de.wikipedia.org/wiki/Erstaufnahmeeinrichtung_(Deutschland https://www.openstreetmap.org/way/437966337 or https://umap.openstreetmap.fr/en/map/jungle-calais_71247#17 ? If yes, this might need some specification.

Good point, this proposal should also be suitable for those refugee sites and european refugee sites as you said. According to you, what kind of specifications should be added then ?

The second question is how strict you see "under operation of the UNHCR or another organization (other NGO, government agency, etc.)" so do you explicetly not include informal/"unmanaged" camps?

This is a good point too, and it’s true that according to this present proposal definition, one can understand that the tag apply only to “formal” refugee site, but it should not be understand this way, “informal” refugee site should also be mapped in OSM with the “generic” tag place=refugee_site. We could then complete/adapt the definition

Best

--MomoMilkiway (talk) 06:07, 10 March 2020 (UTC)

Voting by new user accounts

4 approval votes came in very close together (link to page history) from 4 new user accounts with no previous history:

• https://wiki.openstreetmap.org/wiki/Special:Contributions/0live
• https://wiki.openstreetmap.org/wiki/Special:Contributions/Ed07
• https://wiki.openstreetmap.org/wiki/Special:Contributions/Maevedf
• https://wiki.openstreetmap.org/wiki/Special:Contributions/Paola

Just checking: are these new accounts of people who have already been mappers and active in the community, but just never made a wiki account? In that case, it is appropriate. But if this is sock-puppeting (creation of accounts to merely to affect the vote without history or intention of being involved in OpenStreetMap) that is wrong. I hope and expect that this is not the case. --Jeisenbe (talk) 23:36, 17 March 2020 (UTC)

Also https://wiki.openstreetmap.org/wiki/Special:Contributions/Jamozvan --Jeisenbe (talk) 23:36, 17 March 2020 (UTC)

I have the feeling that the five users did not vote because they agree with the proposed tags but because they have been asked to vote.

The tagging proposal process is based on trust. I strongly advise the authors of the proposal to declare the voting invalid and improve the parts criticised by other mappers. When a proposal is not good and improvements are possible, the improvements should be applied to the proposal and RFC and voting repeated instead of trying to game the voting in order to make it pass. --Nakaner (talk) 12:03, 18 March 2020 (UTC)

The voting period has closed yesterday.

If we don’t take into consideration the last 2 answers that arrived too late, the final count is the following:

For: 27 / Against: 11 (the 3rd negative vote no being signed is not valid) / Blank: 1

Therefore a total of 71% of positive votes on expressed opinions. Based on the current guidelines, and even though the percentage of positive votes required is quite unclear (74% is mentioned as an example… “but other factors may also be considered”) we agree it is safer to consider the proposal refused.

We have been surprised by the large number of negative votes that have appeared on the final hours of the voting, many without detailed comments and none with counter-propositions (as it is expressly recommended by the guidelines), even though there was a 6-weeks period before to comment and vote on it. This is why we have asked colleagues and friends, all of them existing OSM contributors (some of which have indeed created their OSM wiki account for this… many contributors don’t have a Wiki account – you can ask them individually if you want to spend time verifying it), and experts on the topic, to balance these last-minute negative votes.

As it turns out, this wasn’t enough. It is of course always frustrating to see several weeks of efforts, answering comments and amending the proposal thanks to the many interesting contributions we have received, be cancelled like this. We will nevertheless re-submit a proposal in the coming days, in order to keep improving the proposal with the new comments received, and ask for support from more community members who are active and interested in the topic to back it up (many contributors work on refugees site mapping but not necessarily following tag proposal votes).

We also hope next time all contributors will be constructive, avoid last-minute negative votes, and bring suggestions instead of just refusing a proposal that has been built by experts of the topic and experienced OSM contributors. We are in particular looking forward for suggestions on how to best handle the “place” tag that many experienced users considered appropriate but some others apparently not. Let us not forget OSM is a global project that shouldn’t focus only on the perspective of a single group of users. Mapping of refugee site in OSM has now been done for several years in an uncoordinated and disorganized way, we believe our proposal will improve the quality and consistency of the OSM database. CartONG as an organization will continue trying to abide to its best to the OSM community rules, we trust the collective intelligence of the community will prevail to find the best possible solution! —Preceding unsigned comment added by Manonv (talk • contribs) 17:29, Mar 18, 2020 (UTC)

--Maevedf (talk) 17:39, 18 March 2020 (UTC) Hi there, As there are questions on the new user accounts and I'm one of them, just wanted to introduce myself further! I’m "Maeve (CartONG)" on OSM. I’ve been a small scale contributor on OSM since 2013, either through mapathons or else collecting information when I’m in the field with our different partners. I’ve been deployed to around ten refugee camps, often to give trainings around water and sanitation, health or nutrition household or infrastructure surveys in the camps. I always promote the mapping of the camps on OSM to help better camp management and data sharing and also to be able to improve humanitarian programs there (find out more on how we go about it in relation to the mapping of Water & Sanitation household surveys results in this news I wrote : https://www.cartong.org/news/displaying-wash-infrastructure-household-survey-results-same-map). The question of how refugee camps are tagged in OSM is close to my heart, in particular because our teams are often intermediaries that receive data from other sources that can be put on OSM, but it’s quite strenuous work making that data compatible due to the numerous aspects that are still not fixed in stone in the data model. So I did create a Wiki account to be able to vote when I realised it might not pass, because getting this tag clarified is something that is necessary for us to move forward in continued mapping and data integration around OSM. I do however feel we have done a lot of work on this these past months, and that even though it is not perfect it is already a very good first step that we could have continued revising in the future! So hope we manage to all agree in the next iteration :) Best, Maeve

Suggestions for new proposal

Manonv and Kateregga1, please don't be discouraged by the rejection of this proposal. It is normal for most ideas to be rejected the first time. I think if you make a few changes, you can get this idea accepted by the community.

1) Change the key:

• Several people who opposed this proposal did not like the use of place=*. Most similar things in the place=* key are settlements which are only mapped as nodes.
• And as mentioned in the comments, 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= or amenity=, or a subtag of landuse=residential?

2) Option to map the boundary?

• It was also mentioned that a boundary=refugee_camp boundary relation is an option - please clarify if this should be used to map the outline of a refugee site, when this is verifiable.
• I agree that sometimes only a node will work: that can also be an option

3) Clarify the description

• The description includes too many possibilities: "A refugee site is a place that hosts refugee and/or IDP population and that is under operation of the UNHCR or another organization (other NGO, government agency, etc.). A refugee site can be a temporary site or a long term site." This could include a single building which which is operated by a local church and hosts a single refugee family from another country for a month or two. It could also include a huge semi-permanent settlement with thousands of people, shops, businesses, permanent structures and so on, which is nominally operated by a government agency but which actually functions as a town for many years. The definition needs to be changed so that it is clear what qualifies and what does not.
• See also: "OpenStreetMap maps what is on the ground. However, your proposal restricts the usage of the tag to "camps that [are] under operation of the UNHCR or another organization (other NGO, government agency, etc.)". The operator or the absence of an operator should not be taken into account for a tagging decision. There are very likely camps without an operator but which might still be valid features to map... In addition, your definition excludes any camp operatored by government."

4) Other tags

• Several other tags were mentioned, but not clearly defined: refugee_site:for=*, operational_status=* and official_status=* - either remove these, or define them and explain how they should be used (Probably remove official_status, too vague?).
• Don't use an acronym like "IDP" in the value, it should be spelled out.
• "Keep it simple: to refine a refugee_site, use the key refugee_site=* to refine it" - suggested by another user.

Please keep working on this idea. I think if you respond to the concerns mentioned in the opposing votes and on this talk page, it will be likely to be accepted with a second vote. --Jeisenbe (talk) 12:59, 18 March 2020 (UTC)

Thank you Jeisenbe we will keep working to improved the proposal —Preceding unsigned comment added by Manonv (talk • contribs) 17:29, Mar 18, 2020 (UTC)

Jeisenbe, thank you for a succinct summary of recommended improvement to the proposal. It is very clear and, if followed, would improve the proposal immensely. Manon, All, a couple of points I have further suggestions on: Jeisenbe's point 1), 3rd bullet and point 2), 2nd bullet: I do not think a landuse=* area would be ideal, as I think it would be good to be able to map refugee camps as nodes also, but using landuse=* on nodes is not ideal. Using amenity=social_facility seems like the best solution to me, as it describes the function and purpose of the facility, and can coexist with other tags that in my opinion would be perfectly valid, such as landuse=residential and place=town. --Øukasz (talk) 11:07, 19 March 2020 (UTC)

Further, I am also uneasy about the fact that this work, done in agreement with (I am tempted to ask if paid for by? Not that I would object, but just to be clear where this is coming from) UNHCR, relies on the term "refugee." UNHCR uses this term in a strict legal sense, and applying it to people who do not meet this legal definition is bound to create misunderstandings. This is directly addressed above in the proposal under heading "Refugee vs IDP," but I do not believe the proposed compromise is a good one. Thank you for all the work so far and for considering my suggestions!--Øukasz (talk) 11:07, 19 March 2020 (UTC)

Thank you for you participation on this proposal, we try to adapt this first proposal, please visit the new Proposal feature wiki page

https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2

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