[Tagging] Feature Proposal - RFC - Refugee Site Location

Joseph Eisenberg joseph.eisenberg at gmail.com
Sat Apr 4 00:57:11 UTC 2020


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 <joseph.eisenberg at 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
> 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 <europeanwaterproject at gmail.com> 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 <m_viou at cartong.org> 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 <https://wiki.openstreetmap.org/wiki/Key:place>=neighbourhood
>>>
>>> <https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood>/suburb
>>>    <https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb>/village
>>>    <https://wiki.openstreetmap.org/wiki/Tag:place%3Dvillage>/town
>>>    <https://wiki.openstreetmap.org/wiki/Tag:place%3Dtown>
>>>    - + 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]
>>> <http://www.cartong.org>
>>>
>>> Manon Viou
>>>
>>> *Coordinatrice projet Missing Maps*
>>>
>>> [image: Email:] m_viou at 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 at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>



More information about the Tagging mailing list