[Tagging] Feature Proposal - RFC - Refugee Site Location

European Water Project europeanwaterproject at gmail.com
Sat Apr 4 13:18:14 UTC 2020 

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 = XXXX, harbour = YYYYY, and waterway = ZZZZZ ?

Best regards,

Stuart



On Sat, 4 Apr 2020 at 11:16, Joseph Eisenberg <joseph.eisenberg at gmail.com>
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 <europeanwaterproject at gmail.com> 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.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
> >> >>
> >> >
> >>
> >> _______________________________________________
> >> Tagging mailing list
> >> Tagging at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200404/d977b5d3/attachment-0001.htm>

More information about the Tagging mailing list