> 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 <europeanwaterproj...@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.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 >> 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 <europeanwaterproj...@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_v...@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_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 mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
