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
