<div dir="ltr">Dear Joseph,<div><br></div><div>A couple of questions as the use of a clean namespace will all data segregated seems appealing :</div><div><br></div><div>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. </div><div><br></div><div>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 ?
</div><div><br></div><div>3. How about a non-KISS suboptimal tagging with a bit of reduncancy using amenity = refugee_site plus the full namespace ?</div><div><br></div><div>for example : </div><div>amenity=refugee_site</div><div>refugee_site = yes</div><div><span style="color:rgb(0,0,0)">refugee_site:for = internally_displaced/refugee_o</span><span style="color:rgb(0,0,0)">nly/mixed</span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">refugee_site:operator = UNHCR/Red Cross/etc.</span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">refugee_site:duration = permanent/temporary</span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">refugee_site:population = 500,000</span></div><div><span style="color:rgb(0,0,0)">refugee_site:structure=shelter</span><span style="color:rgb(0,0,0)">s/tents/multifunctional/mixed</span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">refugee_site:status=formal/inf</span><span style="color:rgb(0,0,0)">ormal</span> <br></div><div><br></div><div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Stuart </div><div><br></div><div><br></div><div><div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com">joseph.eisenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for being willing to work on this and listen to suggestions<br>
from the community.<br>
<br>
I agree that, under the current, very broad definition of<br>
"amenity=social_facility", a single building which is used as a<br>
shelter for refugees could be tagged as "amenity=social_facility", but<br>
a large camp would not be appropriate, nor would a huge, permanent<br>
area with many buildings which has all the characteristics of a<br>
village or town.<br>
<br>
The problem with just using "refugee_site=*" as the main tag is if it<br>
is used for mapping areas, because in this case database users would<br>
have to add special handling just for this key. Instead, it would be<br>
better to use "amenity=refugee_site" or "landuse=refugee_site" or<br>
"man_made=refugree_site", "emergency=refugee_site", or any other<br>
standard "key" which is already used for area features.<br>
<br>
Explanation:<br>
<br>
There is no native "area" object in the Openstreetmap database.<br>
Instead, to map areas we make a way (a line) which loops back to the<br>
first node. This called a "closed way", and it could represent a line<br>
(for example, a barrier=fence which loops around a field, or a<br>
highway=raceway which is a loop), or also an area.<br>
<br>
To distinguish between these two options for what a closed way can<br>
mean, database users have to look at the tags on the feature, and<br>
guess if it is meant to be an area or a line.<br>
<br>
For example, the iD editor on <a href="http://openstreetmap.org" rel="noreferrer" target="_blank">openstreetmap.org</a> has a list of keys<br>
which are considered to be areas:<br>
<a href="https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json" rel="noreferrer" target="_blank">https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json</a><br>
(documented at <a href="https://github.com/osmlab/id-area-keys" rel="noreferrer" target="_blank">https://github.com/osmlab/id-area-keys</a>)<br>
<br>
This includes "amenity=*", "landuse=*", "place=*", "man_made=",<br>
"emergency=", "healthcare=" and many others, but of course it doesn't<br>
include "refugee_site=" since this key does not yet exist.<br>
<br>
Openstreetmap Carto, the style used to render the Standard map layer<br>
on <a href="http://openstreetmap.org" rel="noreferrer" target="_blank">openstreetmap.org</a>, also has a list of keys and tags which represent<br>
areas: <a href="https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua" rel="noreferrer" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua</a><br>
<br>
"Objects with any of the following keys will be treated as polygon<br>
" local polygon_keys = {<br>
...<br>
'amenity',<br>
...<br>
'club',<br>
...<br>
'emergency',<br>
...<br>
'healthcare',<br>
...<br>
'landuse',<br>
...<br>
'man_made',<br>
etc.<br>
<br>
Also, relations with type=multipolygon and type=boundary are considered areas.<br>
<br>
To render a map of the whole planet, every closed way with one of<br>
these tags is imported into a special rendering database.<br>
<br>
If you want to add a new key to this list, all of the rendering<br>
servers have to reload the database. This process takes all day, so<br>
the servers are not reloaded very often.<br>
<br>
So, if you propose mapping refugee sites as areas and not only as<br>
nodes, they should use one of these common area feature keys, that<br>
database users will be able to start showing these features sooner and<br>
more easily.<br>
<br>
It would also be possible to map them as a boundary relation, but that<br>
only works for areas, not nodes, and I believe the proposal suggests,<br>
appropriately, that a node should be used when the boundaries of the<br>
area are not clearly defined<br>
<br>
(My preference would be for amenity=refugee_site, to fit with<br>
amenity=social_facility and similar area features. The key "amenity"<br>
is used for a very wide variety of features, and it's the best option<br>
for an area feature that does not fit into a more specific category.)<br>
<br>
-- Joseph Eisenberg<br>
<br>
On 4/4/20, European Water Project <<a href="mailto:europeanwaterproject@gmail.com" target="_blank">europeanwaterproject@gmail.com</a>> wrote:<br>
> Dear Manon,<br>
><br>
> This new proposal is a big improvement over the previous proposal and<br>
> properly addresses the many objections to place=refugee_site.<br>
><br>
> A flexible namespace with segregated data related to refugee sites will<br>
> allow ongoing refugee site data maintenance by facilitating operator source<br>
> data comparison in addition to easy refugee site data extraction (objective<br>
> #3).<br>
><br>
> I am supportive.<br>
><br>
> Best regards,<br>
><br>
> Stuart<br>
><br>
> On Fri, 3 Apr 2020 at 16:54, Manon Viou <<a href="mailto:m_viou@cartong.org" target="_blank">m_viou@cartong.org</a>> wrote:<br>
><br>
>> Dear All,<br>
>><br>
>> Discussions continue regarding how to best tag places sheltering refugees<br>
>> and/or internally displaced persons.<br>
>><br>
>> Before jumping into the discussion regarding the pros and cons of the<br>
>> alternative solutions debated so far, I want to recap our objectives.<br>
>><br>
>> *Objectives :*<br>
>><br>
>> - develop a general set of tags which satisfy all the tagging<br>
>> requirements of the many colors and flavors of refugee sites which exist<br>
>> in<br>
>> the world.<br>
>> - develop tags which allow one to describe the features of the refugee<br>
>> site element, such as the "operator" (eg.UNHCR) , the type of population<br>
>> (refugee_only/internally_displaced), if the site is formal or informal,<br>
>> the<br>
>> refugee population, etc ..<br>
>> - develop tags which allow easy refugee site data extraction from the<br>
>> OpenStreetMap database using Overpass by anyone who wants to display<br>
>> refugee sites on a map.<br>
>><br>
>> We welcome all constructive suggestions which help meet these goals. If<br>
>> anyone has any suggestions for improvements of the objectives, we welcome<br>
>> those too.<br>
>><br>
>><br>
>> *State of current discussions:*<br>
>><br>
>> In our second feature proposal we first tried to better defend the use of<br>
>> the key:place, but it seems that a majority of people are opposed to the<br>
>> use of it.<br>
>><br>
>> We have recently received two suggestions which we have combined below in<br>
>> a manner which we believe could meet the stated objectives :<br>
>><br>
>> *Key refugee_site for large facilities *<br>
>><br>
>> The key refugee_site=yes is added to a place tag.<br>
>><br>
>> - place <<a href="https://wiki.openstreetmap.org/wiki/Key:place" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Key:place</a>>=neighbourhood<br>
>> <<a href="https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood</a>>/suburb<br>
>> <<a href="https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb</a>>/village<br>
>> <<a href="https://wiki.openstreetmap.org/wiki/Tag:place%3Dvillage" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:place%3Dvillage</a>>/town<br>
>> <<a href="https://wiki.openstreetmap.org/wiki/Tag:place%3Dtown" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:place%3Dtown</a>><br>
>> - + landuse=residential<br>
>> - + refugee_site=yes.<br>
>><br>
>> The tag refugee_site=yes will allows to easily add secondary optional<br>
>> information to be able to details the typology of the camps and other<br>
>> valuable information like:<br>
>><br>
>> - + refugee_site:for = internally_displaced/refugee_only/mixed<br>
>> - + refugee_site:operator = UNHCR/Red Cross/etc.<br>
>> - + refugee_site:duration = permanent/temporary<br>
>> - + refugee_site:population = 500,000<br>
>> - + refugee_site:structure=shelters/tents/multifunctional/mixed<br>
>> - + refugee_site:status=formal/informal<br>
>><br>
>> *Key Amenity=social_facility for small facilities [a majority agreed<br>
>> that<br>
>> social_facility is not appropriate for large site]*<br>
>><br>
>> For small facilities (less than 5 buildings) also sheltering refugee (for<br>
>> instance: refugee centers, accommodation center, care and hosting<br>
>> center),<br>
>> that are not exactly what we can call refugee site, use the existing tag:<br>
>><br>
>> - amenity=social_facility<br>
>> - + social_facility=shelter<br>
>> - + social_facility:for= internally_displaced/refugee<br>
>><br>
>> Thank you for your consideration,<br>
>><br>
>> [image: CartONG- Humanitarian mapping and information management]<br>
>> <<a href="http://www.cartong.org" rel="noreferrer" target="_blank">http://www.cartong.org</a>><br>
>><br>
>> Manon Viou<br>
>><br>
>> *Coordinatrice projet Missing Maps*<br>
>><br>
>> [image: Email:] <a href="mailto:m_viou@cartong.org" target="_blank">m_viou@cartong.org</a> | [image: Skype:] manon.viou<br>
>> [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839<br>
>><br>
>> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E<br>
>> _______________________________________________<br>
>> Tagging mailing list<br>
>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
>><br>
><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>