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