Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[António Madeira]

If a refugee site has a well established name (and, unfortunately, there
are many examples all over the world), I don't see why it can't have a
"place" tag.

Às 18:24 de 17/04/2020, lukas-...@web.de escreveu:

Hi,
my question is whether this then rather would be something for the
"place" tag? Or did we maybe have that discussion already?
--Lukas
*Gesendet:* Freitag, 17. April 2020 um 18:28 Uhr
*Von:* "Manon Viou" 
*An:* "Tag discussion, strategy and related tools"

*Betreff:* Re: [Tagging] Feature Proposal - RFC - Refugee Site Location
Hello everyone,
It seems I haven't been very clear in my explanations; I sometimes
have a bit of trouble choosing the right word (especially in English).
And I think the “small”/”large” discussion is going the wrong direction…
The new tag we want to propose is to map refugee camps or as it’s
seems better to say in English now : refugee sites. So we want to map
*human settlement*.
The social_facility=shelter tag is very suitable to map single or
individual building or a small group of buildings like a refugee
center, an accommodation center or a care and hosting center for refugees.
But (according to many people now)  the social_facility=shelter 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.
kind regards,
Manon

Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
On 17/4/20 5:29 am, Manon Viou wrote:

Hello,
According to Martin and Warin, the difference between large
and small refugee site is not clear enough,
Martin suggested to use population capacity, for instance less
than 200 people fro small refugee site,
Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee
(for instance: refugee centers, accommodation center, care and
hosting center, church) are not exactly what we can call
refugee site. the difference, beyond the number of building,
number of population or square meter, is quite obvious.

?? How is it 'obvious'???

I have no idea of what that 'obvious' thing is!

Is it really necessary to set a precise rule ?

At the moment there is nothing that can be used to distinguish
between the two.

Suggestion have been made on the number of buildings, number of
people and the area.

Please tell us how you distinguish between them.

I would rather suggest to share some example (like the ones
mentioned above) in order to help contributors to decide if it
rather an amenity=refugee_site or a social_facility=shelter.

Examples are fine. But there must be a statement in words of the
difference between them.

Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com>
<mailto:61sundow...@gmail.com> a écrit :
On 16/4/20 1:23 am, Manon Viou wrote:

Thanks Martin, yes, refugee sites should always be
temporary even if, as you said, some turn to be very
long term places. That's why we do not suggest to add
temporary/permanent options.
Manon

In which case the description for amenity=social_facility
+ social_facility=shelter is not correct.

If it is to be done on area then specify the number of
square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An
area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may
not be possible.

Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com
<mailto:dieterdre...@gmail.com>> a écrit :
sent from a phone

On 15. Apr 2020, at 01:13, Warin <
61sundow...@gmail.com
<mailto:61sundow...@gmail.com>> wrote:
I would think amenity=refugee_site is an area
set aside for the non-temporary residential
use of refugees

maybe I’m a dreamer, but I would expect all
refugee related features to be “temporary”, even
if we are talking about relatively long periods of
time
Cheers Martin

___
Tagging mailing list
Tagging@openstreetmap.org  <mailto:Taggin

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Lukas-458]

Hi,

my question is whether this then rather would be something for the "place" tag? Or did we maybe have that discussion already?


 

--Lukas

 

Gesendet: Freitag, 17. April 2020 um 18:28 Uhr
Von: "Manon Viou" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - Refugee Site Location



Hello everyone,

 

It seems I haven't been very clear in my explanations; I sometimes have a bit of trouble choosing the right word (especially in English). And I think the “small”/”large” discussion is going the wrong direction…

 

The new tag we want to propose is to map refugee camps or as it’s seems better to say in English now : refugee sites. So we want to map human settlement.

 

The social_facility=shelter tag is very suitable to map single or individual building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.

 

But (according to many people now)  the social_facility=shelter 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.

 

kind regards, 

Manon

 


Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
 
On 17/4/20 5:29 am, Manon Viou wrote:


Hello, 

According to Martin and Warin, the difference between large and small refugee site is not clear enough, 
Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 

Warin suggested to use number of square meters, 

For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious.


 

?? How is it 'obvious'???

 

I have no idea of what that 'obvious' thing is!

 

 


Is it really necessary to set a precise rule ?


 

At the moment there is nothing that can be used to distinguish between the two.

Suggestion have been made on the number of buildings, number of people and the area.

 

Please tell us how you distinguish between them.

 


I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 


 

Examples are fine. But there must be a statement in words of the difference between them.


Regards, 

Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :
 
On 16/4/20 1:23 am, Manon Viou wrote:


Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 

Manon


 

In which case the description for amenity=social_facility + social_facility=shelter is not correct.

 

If it is to be done on area then specify the number of square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may not be possible. 

 



Le 15 avril 2020 à 11:36, Martin Koppenhoefer < dieterdre...@gmail.com> a écrit :

 

sent from a phone

 


On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com> wrote:

 

I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees


 

maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time

 

Cheers Martin

 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou



 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou
 +33 (0)4 79 26 28 82 |  +33 (0)7 83889839

 Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E

___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Hello everyone,
   
   

   
   
It seems I haven't been very clear in my explanations; I sometimes have a bit of trouble choosing the right word (especially in English). And I think the “small”/”large” discussion is going the wrong direction…
   
   

   
   
The new tag we want to propose is to map refugee camps or as it’s seems better to say in English now : refugee sites. So we want to map 
human settlement.
   
   

   
   
The social_facility=shelter tag is very suitable to map single or individual building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.
   
   

   
   
But (according to many people now)  the social_facility=shelter 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.
   
   

   
   
kind regards, 
   
   
Manon
   
   

   
  
  
   Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
On 17/4/20 5:29 am, Manon Viou wrote: 

   
   

 Hello, 


 According to Martin and Warin, the difference between large and small refugee site is not clear enough,  
 Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 


 Warin suggested to use number of square meters, 


 For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious.

   
   
   ?? How is it 'obvious'??? 
   
   I have no idea of what that 'obvious' thing is! 
   
   
   

 Is it really necessary to set a precise rule ?

   
   
   At the moment there is nothing that can be used to distinguish between the two. 
   Suggestion have been made on the number of buildings, number of people and the area. 
   
   Please tell us how you distinguish between them. 
   
   

 I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 

   
   
   Examples are fine. But there must be a statement in words of the difference between them. 
   

 Regards, 


 Manon


 Le 16 avril 2020 à 02:16, Warin 
 <61sundow...@gmail.com> a écrit : 
 
 
 
  On 16/4/20 1:23 am, Manon Viou wrote: 
  
 
 
  
   Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 
  
  
   Manon
  
 
 
 In which case the description for amenity=social_facility + social_facility=shelter is not correct. 
 
 If it is to be done on area then specify the number of square meters rather than the number of buildings???
 Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.
 Imagery may not be up to date so counting buildings may not be possible. 
 
 
  
   
Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
dieterdre...@gmail.com> a écrit :
   
   

   
   
sent from a phone
   
   

   
   

 On 15. Apr 2020, at 01:13, Warin < 
 61sundow...@gmail.com> wrote:


 


 I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees

   
   

   
   
maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time
   
   

   
   
Cheers Martin
   
  
  
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

 
 ___ 
 Tagging mailing list 
 
 Tagging@openstreetmap.org 
 
 https://lists.openstreetmap.org/listinfo/tagging 
 


  


 
 Manon Viou
 Coordinatrice projet Missing Maps
  m_v...@cartong.org |  manon.viou

   
   ___ 
   Tagging mailing list 
   Tagging@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/tagging 
   
  
  
    
  
  
   
   Manon Viou
   

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Martin Koppenhoefer]

sent from a phone

> On 16. Apr 2020, at 23:33, António Madeira  wrote:
> 
> Do we divide big schools from small schools? Or small theatres from big 
> theatres?


things can change nature just by changing size or quantity. We have different 
tags for a single tree and a tree row and a forest. We also have different tags 
for a stream and a river, for a bakery and a factory which produces brea. Or 
hamlet, village, town and city. There could be reasons to distinguish 
facilities by size, provided they are changing nature due to / along with size. 


> There are refugee_sites which are de facto towns and villages, so those would 
> be mapped as a normal place.


they could get additional qualifiers (or additionally the amenity =refugee_site 
tag).

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

On 17/4/20 5:29 am, Manon Viou wrote:

Hello,
According to Martin and Warin, the difference between large and small 
refugee site is not clear enough,
Martin suggested to use population capacity, for instance less than 
200 people fro small refugee site,

Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee (for 
instance: refugee centers, accommodation center, care and hosting 
center, church) are not exactly what we can call refugee site. the 
difference, beyond the number of building, number of population or 
square meter, is quite obvious.



?? How is it 'obvious'???


I have no idea of what that 'obvious' thing is!




Is it really necessary to set a precise rule ?



At the moment there is nothing that can be used to distinguish between 
the two.


Suggestion have been made on the number of buildings, number of people 
and the area.



Please tell us how you distinguish between them.


I would rather suggest to share some example (like the ones mentioned 
above) in order to help contributors to decide if it rather an 
amenity=refugee_site or a social_facility=shelter.



Examples are fine. But there must be a statement in words of the 
difference between them.



Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :

On 16/4/20 1:23 am, Manon Viou wrote:
Thanks Martin, yes, refugee sites should always be temporary even 
if, as you said, some turn to be very long term places. That's why 
we do not suggest to add temporary/permanent options.

Manon



In which case the description for amenity=social_facility + 
social_facility=shelter is not correct.



If it is to be done on area then specify the number of square meters 
rather than the number of buildings???


Buildings can be a of different sizes and capacities. An area could 
be more consistent as to the number of people.


Imagery may not be up to date so counting buildings may not be possible.


Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
dieterdre...@gmail.com > a écrit :


sent from a phone

On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com 
> wrote:


I would think amenity=refugee_site is an area set aside for the 
non-temporary residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related 
features to be “temporary”, even if we are talking about relatively 
long periods of time


Cheers Martin


___
Tagging mailing list
Tagging@openstreetmap.org  
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


CartONG- Humanitarian mapping and information management 



Manon Viou

*Coordinatrice projet Missing Maps*

Email: m_v...@cartong.org  | Skype: manon.viou



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[António Madeira]

Maybe I missed something on this long thread but I don't understand why
we need to divide large refugee site from small refugee site. Why create
ambiguities if all of them are refugee sites?
Do we divide big schools from small schools? Or small theatres from big
theatres?
Why don't we just create the amenity=refugee_site tag and populate it
with basic keys like name, operator, population, etc. and then map
whatever exists inside that area, be it buildings, social facilities,
etc. There are refugee_sites which are de facto towns and villages, so
those would be mapped as a normal place.

Às 16:29 de 16/04/2020, Manon Viou escreveu:

Hello,
According to Martin and Warin, the difference between large and small
refugee site is not clear enough,
Martin suggested to use population capacity, for instance less than
200 people fro small refugee site,
Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee (for
instance: refugee centers, accommodation center, care and hosting
center, church) are not exactly what we can call refugee site. the
difference, beyond the number of building, number of population or
square meter, is quite obvious. Is it really necessary to set a
precise rule ? I would rather suggest to share some example (like the
ones mentioned above) in order to help contributors to decide if it
rather an amenity=refugee_site or a social_facility=shelter.
Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :

On 16/4/20 1:23 am, Manon Viou wrote:

Thanks Martin, yes, refugee sites should always be temporary even
if, as you said, some turn to be very long term places. That's why
we do not suggest to add temporary/permanent options.
Manon



In which case the description for amenity=social_facility +
social_facility=shelter is not correct.


If it is to be done on area then specify the number of square meters
rather than the number of buildings???

Buildings can be a of different sizes and capacities. An area could
be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may not be possible.



Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com > a écrit :

sent from a phone


On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com
> wrote:

I would think amenity=refugee_site is an area set aside for the
non-temporary residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related
features to be “temporary”, even if we are talking about relatively
long periods of time

Cheers Martin


___
Tagging mailing list
Tagging@openstreetmap.org  
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


CartONG- Humanitarian mapping and information management


Manon Viou

*Coordinatrice projet Missing Maps*

Email: m_v...@cartong.org  | Skype: manon.viou
Phone: +33 (0)4 79 26 28 82 | Mobile: +33 (0)7 83889839

Address: Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   Hello, 
  
  
   According to Martin and Warin, the difference between large and small refugee site is not clear enough, 
   Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 
  
  
   Warin suggested to use number of square meters, 
  
  
   For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious. Is it really necessary to set a precise rule ? I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 
  
  
   Regards, 
  
  
   Manon
  
  
   Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
On 16/4/20 1:23 am, Manon Viou wrote: 

   
   

 Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 


 Manon

   
   
   In which case the description for amenity=social_facility + social_facility=shelter is not correct. 
   
   If it is to be done on area then specify the number of square meters rather than the number of buildings???
   Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.
   Imagery may not be up to date so counting buildings may not be possible. 
   
   

 
  Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
  dieterdre...@gmail.com> a écrit :
 
 
  
 
 
  sent from a phone
 
 
  
 
 
  
   On 15. Apr 2020, at 01:13, Warin < 
   61sundow...@gmail.com> wrote:
  
  
   
  
  
   I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees
  
 
 
  
 
 
  maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time
 
 
  
 
 
  Cheers Martin
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

   
   ___ 
   Tagging mailing list 
   Tagging@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/tagging 
   
  
  
    
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

On 16/4/20 1:23 am, Manon Viou wrote:
Thanks Martin, yes, refugee sites should always be temporary even if, 
as you said, some turn to be very long term places. That's why we do 
not suggest to add temporary/permanent options.

Manon



In which case the description for amenity=social_facility + 
social_facility=shelter is not correct.



If it is to be done on area then specify the number of square meters 
rather than the number of buildings???


Buildings can be a of different sizes and capacities. An area could be 
more consistent as to the number of people.


Imagery may not be up to date so counting buildings may not be possible.


Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
dieterdre...@gmail.com > a écrit :


sent from a phone

On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com 
> wrote:


I would think amenity=refugee_site is an area set aside for the 
non-temporary residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related features 
to be “temporary”, even if we are talking about relatively long 
periods of time


Cheers Martin


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Martin Koppenhoefer]

Am Mi., 15. Apr. 2020 um 17:37 Uhr schrieb Manon Viou :

> Hello again Martin,
> I agree large and small are quite relative concepts, I proposed to set a
> threshold to "less than 5 buildings" because it was the easiest way I
> found. I'm not sure counting people is feasible at least for remote mapping
> or data integration from NGO or other organisations who don't publicly
> share population information.
> Small refugee sites are in general single structure quite easily
> distinguishable from a classic refugee camp.
> Regards,
>


Yes, sorry for being ambiguos, I did not mean to literally count people,
rather to give an indication how many people are "big" or "small", e.g. 10,
50, 100, 1000, etc.
If the limit is 20 and there are 22 people, you might still decide to make
it "small", but if you see there are around a hundred and the limit is 20,
you will not have to count to say it is "big". Of course, a few hundred
would still be small compared to a place with 20.000 people.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   Hello again Martin, 
   I agree large and small are quite relative concepts, I proposed to set a threshold to "less than 5 buildings" because it was the easiest way I found. I'm not sure counting people is feasible at least for remote mapping or data integration from NGO or other organisations who don't publicly share population information. 
   Small refugee sites are in general single structure quite easily distinguishable from a classic refugee camp. 
   Regards, 
  
  
   Manon
  
  
   
Le 15 avril 2020 à 11:42, Martin Koppenhoefer <
dieterdre...@gmail.com> a écrit :
   
   

   
   
sent from a phone
   
   

   
   

 On 15. Apr 2020, at 10:17, Manon Viou <
 m_v...@cartong.org> wrote:


 


 amenity=refugee_site and amenity=social_facility + social_facility=shelter.


 amenity=refugee_site is for large refugee site


 amenity=social_facility and social_facility=shelter is f or small refugee site (less than 5 buildings) and single structure

   
   

   
   
large is a very relative concept, and counting “buildings or structures is not suitable to distinguish them (you can have 1 person living in a building, or thousands). If we’re to set a kind of threshold I’d rather expect counting people or maybe families/households.
   
   

   
   
Cheers Martin
   
  
  
   
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 
  
  
   Manon
  
  
   
Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com> a écrit :
   
   

   
   
sent from a phone
   
   

   
   

 On 15. Apr 2020, at 01:13, Warin <
 61sundow...@gmail.com> wrote:


 


 I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees

   
   

   
   
maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time
   
   

   
   
Cheers Martin
   
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Martin Koppenhoefer]

sent from a phone

> On 15. Apr 2020, at 10:17, Manon Viou  wrote:
> 
> amenity=refugee_site and amenity=social_facility + social_facility=shelter.  
> amenity=refugee_site is for large refugee site 
> amenity=social_facility and social_facility=shelter is f or small refugee 
> site (less than 5 buildings)  and single structure


large is a very relative concept, and counting “buildings or structures is not 
suitable to distinguish them (you can have 1 person living in a  building, or 
thousands). If we’re to set a kind of threshold I’d rather expect counting 
people or maybe families/households.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Martin Koppenhoefer]

sent from a phone

> On 15. Apr 2020, at 01:13, Warin <61sundow...@gmail.com> wrote:
> 
> I would think amenity=refugee_site is an area set aside for the non-temporary 
> residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related features to be 
“temporary”, even if we are talking about relatively long periods of time

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   Hello Warin, 
  
  
   the description does ditinguish amenity=refugee_site and amenity=social_facility + social_facility=shelter. 
   amenity=refugee_site is 
   for large refugee site
   
  
  
   amenity=social_facility and social_facility=shelter is f
   or small refugee site (less than 5 buildings)  and single structure
  
  
   I invite you to have a look again at the proposal page :
   https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2
   Regards, 
   Manon
  
  
   Le 15 avril 2020 à 01:12, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
Problem.
   
   

   
   
The present description does not distinguish this ' 
amenity=refugee_site' from amenity=social_facility and social_facility=shelter. 
  

   
   
   I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees. 
   The meaning of 'temporary' is not stated in the wiki for social_facility=shelter so there will be some uncertainty as to where teh different lies. 
   
   Possibly the 'area' can be used? A social_facility=shelter could from the wording be considered a single structure? The 'amenity=refugee_site' could be stipulated as many structures i.e. mare than 3? 
   
   
   On 14/4/20 5:41 pm, Manon Viou wrote:
   

 
  Hello,
 
 
  Actually RFC for refugee site location mapping started March 25,
 
 
  Since this day, we received and exchanged on the proposal and made changes to the former proposal, that’s what RFC is all about no?  ,
 
 
  I do not know if according to this changes, we have to restart the RFC period?
 
 
  We will restart RFC period if needed, let me know ! we haven’t received much comments on the latest proposal modifications, please let us know if this works for you or if amendments have to be done ( 
  Proposed features/Refugee Site Location 2)
 
 
  Have a great day,
 
 
  Manon
 
 
  
 


 Le 11 avril 2020 à 00:03, Warin 
 <61sundow...@gmail.com> a écrit : 
 
 
 
  The minimum an RFC is required to be open is 2 weeks.
 
 
  
 
 
  Same with voting.
 
 
  
 
 
  
 
 
  On 11/4/20 1:54 am, Manon Viou wrote: 
  
 
 
  
   
Hello all,
   
   

   
   
We have modified the  
proposed features/Refugee Site Location 2 according to discussions regarding how to best tag places sheltering refugee and/or internally displace persons. Thank you to the contributors who help finding a solution to have a consistent tagging in place for refugee location. 
We are now suggesting to use the tag 
amenity=refugee_site 
   
   

 The tag can be used alternatively on nodes or on areas:


 If the extent of the site is difficult to identify (proximity to other villages, suburban area, etc.) it is recommended to use a node.
 If the extent of the site can be clearly identified from the imagery or field data collection, it is recommended to use an area. Please note this extent does not have to match the official boundary of a camp (which doesn’t necessarily coincide to its physical limitations), as defined by government and specialized agencies, for which a dedicated tag can be used.


 Both approaches can be completed by mapping the landuse=residential of the area and if appropriate a tag place (place=neighbourhood, place=suburb, place=village) can be added in the area of the refugee site. 


 
Please have a look at this new proposal and share your comments quickly if you have any. 
We will close RFC period soon.
   
   

   
   
Best regards,
   
   

   Manon
  
  
   
   Manon Viou
  
 

   
   
  
  
    
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

Problem.

The present description does not distinguish this 
'*amenity=refugee_site*' from amenity=social_facility and 
social_facility=shelter.



I would think amenity=refugee_site is an area set aside for the 
non-temporary residential use of refugees. *

*

The meaning of 'temporary' is not stated in the wiki for 
social_facility=shelter so there will be some uncertainty as to where 
teh different lies.


*
*

Possibly the 'area' can be used? A**social_facility=shelter could from 
the wording be considered a single structure? The 'amenity=refugee_site' 
could be stipulated as many structures i.e. mare than 3?




On 14/4/20 5:41 pm, Manon Viou wrote:


Hello,
Actually RFC for refugee site location mapping started March 25,
Since this day, we received and exchanged on the proposal and made 
changes to the former proposal, that’s what RFC is all about no?  ,
I do not know if according to this changes, we have to restart the RFC 
period?
We will restart RFC period if needed, let me know ! we haven’t 
received much comments on the latest proposal modifications, please 
let us know if this works for you or if amendments have to be done ( 
Proposed features/Refugee Site Location 2 
) 


Have a great day,
Manon


Le 11 avril 2020 à 00:03, Warin <61sundow...@gmail.com> a écrit :

The minimum an RFC is required to be open is 2 weeks.

Same with voting.


On 11/4/20 1:54 am, Manon Viou wrote:

Hello all,

We have modified the proposed features/Refugee Site Location 2 
 according 
to discussions regarding how to best tag places sheltering refugee 
and/or internally displace persons. Thank you to the contributors 
who help finding a solution to have a consistent tagging in place 
for refugee location.

We are now suggesting to use the tag *amenity=refugee_site *
The tag can be used alternatively on nodes or on areas:

  * If the extent of the site is difficult to identify (proximity to
other villages, suburban area, etc.) it is recommended to use a
node.
  * If the extent of the site can be clearly identified from the
imagery or field data collection, it is recommended to use an
area. Please note this extent does not have to match the
official boundary of a camp (which doesn’t necessarily coincide
to its physical limitations), as defined by government and
specialized agencies, for which a dedicated tag can be used.

Both approaches can be completed by mapping the landuse=residential 
of the area and if appropriate a tag place (place=neighbourhood, 
place=suburb, place=village) can be added in the area of the refugee 
site.


Please have a look at this new proposal and share your comments 
quickly if you have any. *We will close RFC period soon*.


Best regards,

Manon

CartONG- Humanitarian mapping and information management 



Manon Viou



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Hello,
   
   
Actually RFC for refugee site location mapping started March 25,
   
   
Since this day, we received and exchanged on the proposal and made changes to the former proposal, that’s what RFC is all about no?  ,
   
   
I do not know if according to this changes, we have to restart the RFC period?
   
   
We will restart RFC period if needed, let me know ! we haven’t received much comments on the latest proposal modifications, please let us know if this works for you or if amendments have to be done (
Proposed features/Refugee Site Location 2)
   
   
Have a great day,
   
   
Manon
   
   

   
  
  
   Le 11 avril 2020 à 00:03, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
The minimum an RFC is required to be open is 2 weeks.
   
   

   
   
Same with voting.
   
   

   
   

   
   
On 11/4/20 1:54 am, Manon Viou wrote: 

   
   

 
  Hello all,
 
 
  
 
 
  We have modified the  
  proposed features/Refugee Site Location 2 according to discussions regarding how to best tag places sheltering refugee and/or internally displace persons. Thank you to the contributors who help finding a solution to have a consistent tagging in place for refugee location. 
  We are now suggesting to use the tag 
  amenity=refugee_site 
 
 
  
   The tag can be used alternatively on nodes or on areas:
  
  
   If the extent of the site is difficult to identify (proximity to other villages, suburban area, etc.) it is recommended to use a node.
   If the extent of the site can be clearly identified from the imagery or field data collection, it is recommended to use an area. Please note this extent does not have to match the official boundary of a camp (which doesn’t necessarily coincide to its physical limitations), as defined by government and specialized agencies, for which a dedicated tag can be used.
  
  
   Both approaches can be completed by mapping the landuse=residential of the area and if appropriate a tag place (place=neighbourhood, place=suburb, place=village) can be added in the area of the refugee site. 
  
  
   
  Please have a look at this new proposal and share your comments quickly if you have any. 
  We will close RFC period soon.
 
 
  
 
 
  Best regards,
 
 
  
 Manon


 
 Manon Viou
 Coordinatrice projet Missing Maps
  m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
  Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

   
   ___ 
   Tagging mailing list 
   Tagging@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/tagging 
   
  
  
    
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

The minimum an RFC is required to be open is 2 weeks.

Same with voting.


On 11/4/20 1:54 am, Manon Viou wrote:

Hello all,

We have modified the proposed features/Refugee Site Location 2 
 according 
to discussions regarding how to best tag places sheltering refugee 
and/or internally displace persons. Thank you to the contributors who 
help finding a solution to have a consistent tagging in place for 
refugee location.

We are now suggesting to use the tag *amenity=refugee_site *
The tag can be used alternatively on nodes or on areas:

  * If the extent of the site is difficult to identify (proximity to
other villages, suburban area, etc.) it is recommended to use a node.
  * If the extent of the site can be clearly identified from the
imagery or field data collection, it is recommended to use an
area. Please note this extent does not have to match the official
boundary of a camp (which doesn’t necessarily coincide to its
physical limitations), as defined by government and specialized
agencies, for which a dedicated tag can be used.

Both approaches can be completed by mapping the landuse=residential of 
the area and if appropriate a tag place (place=neighbourhood, 
place=suburb, place=village) can be added in the area of the refugee 
site.


Please have a look at this new proposal and share your comments 
quickly if you have any. *We will close RFC period soon*.


Best regards,

Manon

CartONG- Humanitarian mapping and information management 



Manon Viou

*Coordinatrice projet Missing Maps*

Email: m_v...@cartong.org  | Skype: manon.viou
Phone: +33 (0)4 79 26 28 82 | Mobile: +33 (0)7 83889839

Address: Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Hello all,
   
   

   
   
We have modified the 
proposed features/Refugee Site Location 2 according to discussions regarding how to best tag places sheltering refugee and/or internally displace persons. Thank you to the contributors who help finding a solution to have a consistent tagging in place for refugee location. 
We are now suggesting to use the tag 
amenity=refugee_site 
   
   

 The tag can be used alternatively on nodes or on areas:


 If the extent of the site is difficult to identify (proximity to other villages, suburban area, etc.) it is recommended to use a node.
 If the extent of the site can be clearly identified from the imagery or field data collection, it is recommended to use an area. Please note this extent does not have to match the official boundary of a camp (which doesn’t necessarily coincide to its physical limitations), as defined by government and specialized agencies, for which a dedicated tag can be used.


 Both approaches can be completed by mapping the landuse=residential of the area and if appropriate a tag place (place=neighbourhood, place=suburb, place=village) can be added in the area of the refugee site. 


 
Please have a look at this new proposal and share your comments quickly if you have any. 
We will close RFC period soon.
   
   

   
   
Best regards,
   
   

   Manon
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

> QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily 
> have to be associated with place or landuse?

As mentioned, it would be fine to use a new "key" like "refugee_site"
for a feature that is only mapped as nodes, but if it is going to be
used on areas it's important to use a well-known, established key.

It's not just important for rendering, but also for routing and search
applications, which also need to know if a closed way is representing
an area or not.

> QUESTION: IWith this option [amenity=refugee_site] could we still proposed 
> the secondary tags refugee_site:XX=XX (for instance 
> refugee_site:status=formal)?

Yes.

> Do we also have to add “refugee_site=yes” or it’s not necessary?

No, if the tag is "amenity=refugee_site", there is no need to add it.

-- Joseph Eisenberg

On 4/6/20, Manon Viou  wrote:
> Dear all,
>
> Thank you Joseph and Stuart for your very valuable comments, these exchanges
> are very constructive and personally I learn a lot about how OSM database
> works.
>
> I agree with both of you, it seems more appropriate to use a node or a
> polygon main top-level key. And it’s true we have this constraint of being
> able to map the refugee site with either node or polygon (Polygon being
> preferable when possible, but sometimes it’s impossible to delimit clearly
> the exact area.)
>
> I will try to resume the options we have left:
>
> First, it’s agreed that the distinction between large and small (less than 5
> buildings) refugee site is necessary.
>
> For small refugee site, the use of the existing
> Amenity=social_facility
> + social_facility=shelter
> + social_facility:for= internally_displaced/refugee
> Does not seem to be a problem
>
> For large refugee site we still have different options
>
> Option 1: The key refugee_site=yes is added to a place tag
> Place = neighbourhood/suburb/village/town
> + refugee_site=yes
> + refugee_site:XX=XX
> -> but if I understand well, it’s not possible to tag a polygon with the tag
> place? if so this option is not relevant to map refugee_site as polygon.
> also it not so easy to identify if the refugee site should be map as a
> neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s
> seems complicated to apply this to all context as she illustrated very well.
>
> Option 2: The key refugee_site=yes is added to a landuse tag
> Landuse = residential
> + refugee_site=yes
> + refugee_site:XX=XX
> -> But if I understand correctly, the use of landuse=residential is not
> always adapted to the refugee site (landuse=residential area, ideally,
> should only include areas that are primarily residential). Also it would be
> wrong to create a new residential area to delimit a refugee site already
> inside a larger residential area. Thus this option seems a bit problematic.
>
> QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily
> have to be associated with place or landuse? And if we could have
> refugee_site=yes without any other tags ? in this case the limits cited
> above would no longer be constraining.
> but if I understand you Joseph, this will be a problem for the rendering ?
>
> Option 3: use an existing main top-level key (from the listed options shared
> by Joseph)
>
> My preference as Joseph and Oukasz would be for the Amenity option, as it
> can apply as well as a node or a polygon, and fit better with the option for
> small refugee site.
> Amenity=refugee_site
> + refugee_site:XX=XX
> QUESTION: I still have 2 questions. With this option could we still proposed
> the secondary tags refugee_site:XX=XX (for instance
> refugee_site:status=formal)? As those secondary tag are very important too
> as mentioned in the talk page and because the diversity of refugee_site is
> such that it’s important to be able to detail the characteristics of it.
> Do we also have to add “refugee_site=yes” or it’s not necessary?
>
>
> About rendering: for sure it’s good to take it into account, but I think
> it’s not a priority, the most important is to ensure a consistency in the
> way to map refugee site in OSM and to facilitate data extraction and data
> maintenance.
>
> I have a more practical question, as the proposition change a lot, what is
> best, create a new proposed feature page “refugee Site Location 3” or can I
> change the “refugee Site Location 2” page ?
>
>
> Thank you for your participation
>
> Have a great day,
>
> Manon
>
> [image: CartONG- Humanitarian mapping and information management]
>
> Manon Viou
>
> Coordinatrice projet Missing Maps
>
> [image: Email:] m_v...@cartong.org | [image: Skype:] manon.viou
> [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839
>
> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Dear all,
   
   

   
   
Thank you Joseph and Stuart for your very valuable comments, these exchanges are very constructive and personally I learn a lot about how OSM database works.
   
   

   
   
I agree with both of you, it seems more appropriate to use a node or a polygon main top-level key. And it’s true we have this constraint of being able to map the refugee site with either node or polygon (Polygon being preferable when possible, but sometimes it’s impossible to delimit clearly the exact area.)
   
   

   
   
I will try to resume the options we have left:
   
   

   
   
First, it’s agreed that the distinction between large and small (less than 5 buildings) refugee site is necessary.
   
   

   
   
For small refugee site, the use of the existing
   
   
Amenity=social_facility
+ social_facility=shelter
+ social_facility:for= "">
   
   
Does not seem to be a problem
   
   

   
   
For large refugee site we still have different options
   
   

   
   
Option 1: The key refugee_site=yes is added to a place tag
   
   
Place = neighbourhood/suburb/village/town
+ refugee_site=yes
+ refugee_site:XX=XX
   
   
-> but if I understand well, it’s not possible to tag a polygon with the tag place? if so this option is not relevant to map refugee_site as polygon. 
also it not so easy to identify if the refugee site should be map as a neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s seems complicated to apply this to all context as she illustrated very well.
   
   

   
   
Option 2: The key refugee_site=yes is added to a landuse tag
   
   
Landuse = residential
+ refugee_site=yes
+ refugee_site:XX=XX
   
   
-> But if I understand correctly, the use of landuse=residential is not always adapted to the refugee site (landuse=residential area, ideally, should only include areas that are primarily residential). Also it would be wrong to create a new residential area to delimit a refugee site already inside a larger residential area. Thus this option seems a bit problematic.
   
   

   
   
QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily have to be associated with place or landuse? And if we could have refugee_site=yes without any other tags ? in this case the limits cited above would no longer be constraining. but if I understand you Joseph, this will be a problem for the rendering ?
   
   

   
   
Option 3: use an existing main top-level key (from the listed options shared by Joseph)
   
   

   
   
My preference as Joseph and Oukasz would be for the 
Amenity option, as it can apply as well as a node or a polygon, and fit better with the option for small refugee site.
   
   
Amenity=refugee_site
+ refugee_site:XX=XX
   
   
QUESTION: I still have 2 questions. With this option could we still proposed the secondary tags refugee_site:XX=XX (for instance refugee_site:status=formal)? As those secondary tag are very important too as mentioned in the talk page and because the diversity of refugee_site is such that it’s important to be able to detail the characteristics of it. 
   
   
Do we also have to add “refugee_site=yes” or it’s not necessary? 
   
   

   
   

   
   
About rendering: for sure it’s good to take it into account, but I think it’s not a priority, the most important is to ensure a consistency in the way to map refugee site in OSM and to facilitate data extraction and data maintenance.
   
   

   
   
I have a more 
practical question, as the proposition change a lot, what is best, create a new proposed feature page “refugee Site Location 3” or can I change the “refugee Site Location 2” page ?
   
   

   
   

   
   
Thank you for your participation
   
   

   
   
Have a great day,
   
   

   
   
Manon
   
   

   
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Hi Joseph,

Yes, agree that given the above constraints it makes sense to use this
namespace as an attachment to a node or an area which has a main top-level
key already included in the local polygon keys object.What is the
process for requesting to have a new key added to the local polygon_keys
object ?

I now have another question, not directly related to this thread.

How are nodes which have multiple top level keys contained in the local
polygon_keys object rendered ? Does each map renderer choose a preference
order if a node has more than one top-level key ? For example, if a node
has amenity = , harbour = Y, and waterway = Z ?

Best regards,

Stuart



On Sat, 4 Apr 2020 at 11:16, Joseph Eisenberg 
wrote:

> > If refugee_site were added to the local polygon_keys object you
> mentioned, how long would it take for the effects of this updated object to
> propagate?
>
> Now that I've re-read the full text of the new proposal, it looks like
> the author is intending refugee_site=* to be added to a feature which
> is also tagged with place=* or landuse=*, so that won't actually be a
> problem in that case.
>
> It's only an issue if there is no other main feature tag used on the
> area. If this tag was only going to be used on place= nodes, that's
> also not a problem.
>
> But if used as the only main tag on a feature, map renderers which use
> osm2pgsql or similar tools will need to reload their rendering
> databases. This only happens about once a year for the servers that
> render the standard style on openstreetmap.org, so I would expect at
> least 2 years before you could imagine seeing this rendered, assuming
> that it becomes quite popular in the next year.
>
> Other map styles could be updated sooner, if they are specialized.
>
> But I think it is better to use a main top-level key.
>
> -- Joseph
>
> On 4/4/20, European Water Project  wrote:
> > Dear Joseph,
> >
> > A couple of questions as the use of a clean namespace will all data
> > segregated seems appealing :
> >
> > 1. If refugee_site were added to the local polygon_keys object you
> > mentioned, how long would it take for the effects of this updated object
> to
> > propagate  ? A couple of weeks, months ? Finding a durable long-term
> clean
> > solution should be the goal.
> >
> > 2. Assuming a couple of days delay for display of a refugee site is
> > acceptable for this use case, do you still have objections to this
> proposal
> > ?
> >
> > 3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
> > amenity = refugee_site plus the full namespace ?
> >
> > for example :
> > amenity=refugee_site
> > refugee_site = yes
> > 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
> >
> >
> >
> > Best regards,
> >
> > Stuart
> >
> >
> >
> >
> > On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg <
> joseph.eisenb...@gmail.com>
> > wrote:
> >
> >> Thank you for being willing to work on this and listen to suggestions
> >> from the community.
> >>
> >> 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
> >> 

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

> If refugee_site were added to the local polygon_keys object you mentioned, 
> how long would it take for the effects of this updated object to propagate?

Now that I've re-read the full text of the new proposal, it looks like
the author is intending refugee_site=* to be added to a feature which
is also tagged with place=* or landuse=*, so that won't actually be a
problem in that case.

It's only an issue if there is no other main feature tag used on the
area. If this tag was only going to be used on place= nodes, that's
also not a problem.

But if used as the only main tag on a feature, map renderers which use
osm2pgsql or similar tools will need to reload their rendering
databases. This only happens about once a year for the servers that
render the standard style on openstreetmap.org, so I would expect at
least 2 years before you could imagine seeing this rendered, assuming
that it becomes quite popular in the next year.

Other map styles could be updated sooner, if they are specialized.

But I think it is better to use a main top-level key.

-- Joseph

On 4/4/20, European Water Project  wrote:
> Dear Joseph,
>
> A couple of questions as the use of a clean namespace will all data
> segregated seems appealing :
>
> 1. If refugee_site were added to the local polygon_keys object you
> mentioned, how long would it take for the effects of this updated object to
> propagate  ? A couple of weeks, months ? Finding a durable long-term clean
> solution should be the goal.
>
> 2. Assuming a couple of days delay for display of a refugee site is
> acceptable for this use case, do you still have objections to this proposal
> ?
>
> 3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
> amenity = refugee_site plus the full namespace ?
>
> for example :
> amenity=refugee_site
> refugee_site = yes
> 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
>
>
>
> Best regards,
>
> Stuart
>
>
>
>
> On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg 
> wrote:
>
>> Thank you for being willing to work on this and listen to suggestions
>> from the community.
>>
>> 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.
>>
>> Openstreetmap Carto, the style used to render the Standard map layer
>> on openstreetmap.org, also has a list of keys and tags which represent
>> areas:
>> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
>>
>> "Objects with any of the following keys will be treated as polygon
>> " local polygon_keys = {
>> ...
>> 'amenity',
>> ...
>> 'club',
>> ...
>> 'emergency',
>> ...
>> 'healthcare',
>> ...
>> 'landuse',
>> ...
>> 'man_made',
>> etc.
>>
>> Also, relations with type=multipolygon and type=boundary are considered
>> areas.
>>
>> To render a map of the whole planet, every closed way with one of
>> these tags is imported into a special rendering database.
>>
>> 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 

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Dear Joseph,

A couple of questions as the use of a clean namespace will all data
segregated seems appealing :

1. If refugee_site were added to the local polygon_keys object you
mentioned, how long would it take for the effects of this updated object to
propagate  ? A couple of weeks, months ? Finding a durable long-term clean
solution should be the goal.

2. Assuming a couple of days delay for display of a refugee site is
acceptable for this use case, do you still have objections to this proposal
?

3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
amenity = refugee_site plus the full namespace ?

for example :
amenity=refugee_site
refugee_site = yes
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



Best regards,

Stuart




On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg 
wrote:

> Thank you for being willing to work on this and listen to suggestions
> from the community.
>
> 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.
>
> Openstreetmap Carto, the style used to render the Standard map layer
> on openstreetmap.org, also has a list of keys and tags which represent
> areas:
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
>
> "Objects with any of the following keys will be treated as polygon
> " local polygon_keys = {
> ...
> 'amenity',
> ...
> 'club',
> ...
> 'emergency',
> ...
> 'healthcare',
> ...
> 'landuse',
> ...
> 'man_made',
> etc.
>
> Also, relations with type=multipolygon and type=boundary are considered
> areas.
>
> To render a map of the whole planet, every closed way with one of
> these tags is imported into a special rendering database.
>
> 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.
>
> It would also be possible to map them as a boundary relation, but that
> only works for areas, not nodes, and I believe the proposal suggests,
> appropriately, that a node should be used when the boundaries of the
> area are not clearly defined
>
> (My preference would be for amenity=refugee_site, to fit with
> amenity=social_facility and similar area features. The key "amenity"
> is used for a very wide variety of features, and it's the best option
> for an area feature that does not fit into a more specific category.)
>
> -- Joseph Eisenberg
>
> On 4/4/20, European Water Project  wrote:
> > Dear Manon,
> >
> > This new proposal is a big improvement over the previous proposal and
> > properly addresses the many objections to place=refugee_site.
> >
> > A flexible namespace with segregated data related to refugee sites will
> > allow ongoing refugee site data maintenance by facilitating operator
> source
> > data comparison in addition to easy refugee site data extraction
> (objective
> > #3).
> 

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

Also, 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 single node, since
settled places do not usually have a well-defined boundary, while
landuse=residential is mapped as an area.

And the landuse=residential area, ideally, should only include areas
that are primarily residential: it's normal to exclude offices,
schools, places of worship, retail areas with shops, and many mappers
excludes the areas of highways, when mapping areas precisely.

So it would not be appropriate to map a large refugee site, which
includes non-residential features, as landuse=residential only.

On 4/4/20, Joseph Eisenberg  wrote:
> Thank you for being willing to work on this and listen to suggestions
> from the community.
>
> 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.
>
> Openstreetmap Carto, the style used to render the Standard map layer
> on openstreetmap.org, also has a list of keys and tags which represent
> areas:
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
>
> "Objects with any of the following keys will be treated as polygon
> " local polygon_keys = {
> ...
> 'amenity',
> ...
> 'club',
> ...
> 'emergency',
> ...
> 'healthcare',
> ...
> 'landuse',
> ...
> 'man_made',
> etc.
>
> Also, relations with type=multipolygon and type=boundary are considered
> areas.
>
> To render a map of the whole planet, every closed way with one of
> these tags is imported into a special rendering database.
>
> 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.
>
> It would also be possible to map them as a boundary relation, but that
> only works for areas, not nodes, and I believe the proposal suggests,
> appropriately, that a node should be used when the boundaries of the
> area are not clearly defined
>
> (My preference would be for amenity=refugee_site, to fit with
> amenity=social_facility and similar area features. The key "amenity"
> is used for a very wide variety of features, and it's the best option
> for an area feature that does not fit into a more specific category.)
>
> -- Joseph Eisenberg
>
> On 4/4/20, European Water Project  wrote:
>> Dear Manon,
>>
>> This new proposal is a big improvement over the previous proposal and
>> properly addresses the many objections to place=refugee_site.
>>
>> A flexible namespace with segregated data related to refugee sites will
>> allow ongoing refugee site data maintenance by facilitating operator
>> source
>> data comparison in addition to easy refugee site data extraction
>> (objective
>> #3).
>>
>> I am supportive.
>>
>> Best regards,
>>
>> Stuart
>>
>> On Fri, 3 Apr 2020 at 16:54, Manon Viou  wrote:
>>
>>> Dear All,
>>>
>>> Discussions continue regarding how to best tag places sheltering
>>> refugees
>>> and/or internally displaced persons.
>>>
>>> Before jumping into the discussion regarding the pros and cons of the
>>> alternative 

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

Thank you for being willing to work on this and listen to suggestions
from the community.

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.

Openstreetmap Carto, the style used to render the Standard map layer
on openstreetmap.org, also has a list of keys and tags which represent
areas: 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua

"Objects with any of the following keys will be treated as polygon
" local polygon_keys = {
...
'amenity',
...
'club',
...
'emergency',
...
'healthcare',
...
'landuse',
...
'man_made',
etc.

Also, relations with type=multipolygon and type=boundary are considered areas.

To render a map of the whole planet, every closed way with one of
these tags is imported into a special rendering database.

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.

It would also be possible to map them as a boundary relation, but that
only works for areas, not nodes, and I believe the proposal suggests,
appropriately, that a node should be used when the boundaries of the
area are not clearly defined

(My preference would be for amenity=refugee_site, to fit with
amenity=social_facility and similar area features. The key "amenity"
is used for a very wide variety of features, and it's the best option
for an area feature that does not fit into a more specific category.)

-- Joseph Eisenberg

On 4/4/20, European Water Project  wrote:
> Dear Manon,
>
> This new proposal is a big improvement over the previous proposal and
> properly addresses the many objections to place=refugee_site.
>
> A flexible namespace with segregated data related to refugee sites will
> allow ongoing refugee site data maintenance by facilitating operator source
> data comparison in addition to easy refugee site data extraction (objective
> #3).
>
> I am supportive.
>
> Best regards,
>
> Stuart
>
> On Fri, 3 Apr 2020 at 16:54, Manon Viou  wrote:
>
>> Dear All,
>>
>> Discussions continue regarding how to best tag places sheltering refugees
>> and/or internally displaced persons.
>>
>> Before jumping into the discussion regarding the pros and cons of the
>> alternative solutions debated so far, I want to recap our objectives.
>>
>> *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.
>>
>> We welcome all constructive suggestions which help meet these goals.  If
>> anyone has any suggestions for improvements of the objectives, we welcome
>> those too.
>>
>>
>> *State of current discussions:*
>>
>> 

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Dear Manon,

This new proposal is a big improvement over the previous proposal and
properly addresses the many objections to place=refugee_site.

A flexible namespace with segregated data related to refugee sites will
allow ongoing refugee site data maintenance by facilitating operator source
data comparison in addition to easy refugee site data extraction (objective
#3).

I am supportive.

Best regards,

Stuart

On Fri, 3 Apr 2020 at 16:54, Manon Viou  wrote:

> Dear All,
>
> Discussions continue regarding how to best tag places sheltering refugees
> and/or internally displaced persons.
>
> Before jumping into the discussion regarding the pros and cons of the
> alternative solutions debated so far, I want to recap our objectives.
>
> *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.
>
> We welcome all constructive suggestions which help meet these goals.  If
> anyone has any suggestions for improvements of the objectives, we welcome
> those too.
>
>
> *State of current discussions:*
>
> In our second feature proposal we first tried to better defend the use of
> the key:place, but it seems that a majority of people are opposed to the
> use of it.
>
> We have recently received two suggestions which we have combined below in
> a manner which we believe could meet the stated objectives :
>
> *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
>
> Thank you for your consideration,
>
> [image: CartONG- Humanitarian mapping and information management]
> 
>
> Manon Viou
>
> *Coordinatrice projet Missing Maps*
>
> [image: Email:] m_v...@cartong.org | [image: Skype:] manon.viou
> [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839
>
> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Dear All,
   
   

   
   
Discussions continue regarding how to best tag places sheltering refugees and/or internally displaced persons.
   
   

   
   
Before jumping into the discussion regarding the pros and cons of the alternative solutions debated so far, I want to recap our objectives. 
   
   

   
   
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. 
   
   

   
   
We welcome all constructive suggestions which help meet these goals.  If anyone has any suggestions for improvements of the objectives, we welcome those too. 
   
   

   
   

   
   
State of current discussions:
   
   

   
   
In our second feature proposal we first tried to better defend the use of the key:place, but it seems that a majority of people are opposed to the use of it.
   
   

   
   
We have recently received two suggestions which we have combined below in a manner which we believe could meet the stated objectives : 
   
   

   
   
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 = "">
+ 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= "">
   
   
Thank you for your consideration, 
   
   

   
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Hi Joseph,

Would segregation of data via a namespace tagging solution, as an
alternative to using place=refugee_site, address these concerns regarding
fuzzy "place" boundaries and the lack of observability (ie source based
descriptive data)?

Best regards,

Stuart


On Thu, Mar 26, 2020, 00:40 Joseph Eisenberg 
wrote:

> In the previous proposal (Proposed features/Refugee Site Location) at
> least 6 people who opposed the proposal mentioned the key "place=" was
> not acceptable.
>
> 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?" (
>
> "Using the place tag for this causes problems in situations where the
> distinction between a refugee camp and a town is vague. Is a
> settlement of over 100,000 people, that's existed for 30 years and has
> schools, hospitals and a graveyard a city or a camp? I think it should
> be tagged as both. If it isn't then OSM will either not have some of
> the biggest refugee camps mapped, or it not have some of the largest
> towns/cities in the area mapped. Either would be a serious omission.
> Because of that, the refugee site should be tagged outside of the
> place tag."
>
> 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.
>
> Also, is there already an Import page set up by CartONG for the
> proposal to import this info from the UNHCR database?
>
> -- Joseph Eisenberg
>
> On 3/25/20, Manon Viou  wrote:
> > Hello,
> >
> > The proposed feature place=refugee_site to provide a way for mapping
> places
> > sheltering refugees and/or internally displaced persons fleeing the
> effects
> > of a natural disaster or a political crisis for example 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 !
> >
> > Please visit the new feature proposal wiki page here :
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2
> >
> > Best regards,
> > Manon
> >
> > [image: CartONG- Humanitarian mapping and information management]
> >
> > Manon Viou
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

In the previous proposal (Proposed features/Refugee Site Location) at
least 6 people who opposed the proposal mentioned the key "place=" was
not acceptable.

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?" (

"Using the place tag for this causes problems in situations where the
distinction between a refugee camp and a town is vague. Is a
settlement of over 100,000 people, that's existed for 30 years and has
schools, hospitals and a graveyard a city or a camp? I think it should
be tagged as both. If it isn't then OSM will either not have some of
the biggest refugee camps mapped, or it not have some of the largest
towns/cities in the area mapped. Either would be a serious omission.
Because of that, the refugee site should be tagged outside of the
place tag."

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.

Also, is there already an Import page set up by CartONG for the
proposal to import this info from the UNHCR database?

-- Joseph Eisenberg

On 3/25/20, Manon Viou  wrote:
> Hello,
>
> The proposed feature place=refugee_site to provide a way for mapping places
> sheltering refugees and/or internally displaced persons fleeing the effects
> of a natural disaster or a political crisis for example 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 !
>
> Please visit the new feature proposal wiki page here :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2
>
> Best regards,
> Manon
>
> [image: CartONG- Humanitarian mapping and information management]
>
> Manon Viou

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Hello,

I followed the recent discussion on the OSM France mailing list.

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.  If place=refugee_site will
always be a standalone entity, a namespace probably wouldn't add much
value.

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

Best regards,

Stuart



On Wed, 25 Mar 2020 at 15:23, Manon Viou  wrote:

> Hello,
>
> The proposed feature *place=refugee_site to provide a way for mapping
> places sheltering refugees and/or internally displaced persons fleeing the
> effects of a natural disaster or a political crisis for example* 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 !
>
> Please visit the new feature proposal wiki page here :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2
>
> Best regards,
> Manon
>
> [image: CartONG- Humanitarian mapping and information management]
> 
>
> Manon Viou
>
> *Coordinatrice projet Missing Maps*
>
> [image: Email:] m_v...@cartong.org | [image: Skype:] manon.viou
> [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839
>
> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   Hello, 
  
  
   
  
  
   
The proposed feature place=refugee_site to provide a way for mapping places sheltering refugees and/or internally displaced persons fleeing the effects of a natural disaster or a political crisis for example 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 ! 
   
   

   
   
Please visit the new feature proposal wiki page here : https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2
   
   

   
   
Best regards, 
   
   
Manon
   
   

   
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Mateusz Konieczny via Tagging]

30 Jan 2020, 10:02 by m_v...@cartong.org:
> We would like to propose a very generic tag this time to map the location of 
> refugee camps. We propose to use the tag  > place=refugee_site
>
> See the proposal wiki page : > 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location
>
What about long term refugee camps 
that turn into villages or towns?

How one should tag such places?
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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Dear all,
   
   

   
   
There is not yet a real consensus within the OSM community regarding the way to reference refugee sites in OSM. As a result, tagging is applied inconsistently which makes it quite difficult to find and use this data. In the past years there have been several attempts to improve the referencing of refugee camps in OSM but they never succeeded in finalizing a full proposal.
   
   

   
   
Humanitarian organizations working with refugees and other displaced populations are willing to open some of their data to OpenStreetMap for wider and sustainable dissemination, but a common framework aligned with OpenStreetMap standards is necessary.
   
   

   
   
Since many individuals and organizations already contribute to OpenStreetMap refugee site mapping efforts, it would benefit everyone to agree on a clear and consistent tagging schema for refugee sites.
   
   

   
   
We would like to propose a very generic tag this time to map the location of refugee camps. We propose to use the tag 
place=refugee_site
   
   

   
   
See the proposal wiki page : 
https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location
   
   

   
   
Thank you for your consideration,
   
   

   
   
And please feel free to comment, preferably directly on the wiki !
   
   

   
   
Kind regards,
   
   

   Manon
  
  
   
   
 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging