<div dir="ltr"><div dir="ltr">Hi Joseph,<div><br></div><div>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 ?</div><div><br></div><div>I now have another question, not directly related to this thread. </div><div><br></div><div>How are nodes which have multiple top level keys contained in the <span style="color:rgb(0,0,0)">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 ?</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Best regards,</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Stuart </span></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 4 Apr 2020 at 11:16, 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">> 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?<br>
<br>
Now that I've re-read the full text of the new proposal, it looks like<br>
the author is intending refugee_site=* to be added to a feature which<br>
is also tagged with place=* or landuse=*, so that won't actually be a<br>
problem in that case.<br>
<br>
It's only an issue if there is no other main feature tag used on the<br>
area. If this tag was only going to be used on place= nodes, that's<br>
also not a problem.<br>
<br>
But if used as the only main tag on a feature, map renderers which use<br>
osm2pgsql or similar tools will need to reload their rendering<br>
databases. This only happens about once a year for the servers that<br>
render the standard style on <a href="http://openstreetmap.org" rel="noreferrer" target="_blank">openstreetmap.org</a>, so I would expect at<br>
least 2 years before you could imagine seeing this rendered, assuming<br>
that it becomes quite popular in the next year.<br>
<br>
Other map styles could be updated sooner, if they are specialized.<br>
<br>
But I think it is better to use a main top-level key.<br>
<br>
-- Joseph<br>
<br>
On 4/4/20, European Water Project <<a href="mailto:europeanwaterproject@gmail.com" target="_blank">europeanwaterproject@gmail.com</a>> wrote:<br>
> Dear Joseph,<br>
><br>
> A couple of questions as the use of a clean namespace will all data<br>
> segregated seems appealing :<br>
><br>
> 1. If refugee_site were added to the local polygon_keys object you<br>
> mentioned, how long would it take for the effects of this updated object to<br>
> propagate ? A couple of weeks, months ? Finding a durable long-term clean<br>
> solution should be the goal.<br>
><br>
> 2. Assuming a couple of days delay for display of a refugee site is<br>
> acceptable for this use case, do you still have objections to this proposal<br>
> ?<br>
><br>
> 3. How about a non-KISS suboptimal tagging with a bit of reduncancy using<br>
> amenity = refugee_site plus the full namespace ?<br>
><br>
> for example :<br>
> amenity=refugee_site<br>
> refugee_site = yes<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>
><br>
><br>
> Best regards,<br>
><br>
> Stuart<br>
><br>
><br>
><br>
><br>
> On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>><br>
> wrote:<br>
><br>
>> 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:<br>
>> <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<br>
>> 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<br>
>> source<br>
>> > data comparison in addition to easy refugee site data extraction<br>
>> (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<br>
>> 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<br>
>> >> exist<br>
>> >> in<br>
>> >> the world.<br>
>> >> - develop tags which allow one to describe the features of the<br>
>> >> refugee<br>
>> >> site element, such as the "operator" (eg.UNHCR) , the type of<br>
>> >> population<br>
>> >> (refugee_only/internally_displaced), if the site is formal or<br>
>> >> 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.<br>
>> >> If<br>
>> >> anyone has any suggestions for improvements of the objectives, we<br>
>> 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<br>
>> of<br>
>> >> the key:place, but it seems that a majority of people are opposed to<br>
>> >> the<br>
>> >> use of it.<br>
>> >><br>
>> >> We have recently received two suggestions which we have combined below<br>
>> 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><br>
>> >=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><br>
>> >/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<br>
>> (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<br>
>> 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<br>
>> 83889839<br>
>> >><br>
>> >> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat:<br>
>> >> 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>
>><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></div>