Dear all,
Thank you Joseph and Stuart for your very valuable comments, these exchanges are very constructive and personally I learn a lot about how OSM database works.
I agree with both of you, it seems more appropriate to use a node or a polygon main top-level key. And it’s true we have this constraint of being able to map the refugee site with either node or polygon (Polygon being preferable when possible, but sometimes it’s impossible to delimit clearly the exact area.)
I will try to resume the options we have left:
First, it’s agreed that the distinction between large and small (less than 5 buildings) refugee site is necessary.
For small refugee site, the use of the existing
- Amenity=social_facility
- + social_facility=shelter
- + social_facility:for= "">
Does not seem to be a problem
For large refugee site we still have different options
Option 1: The key refugee_site=yes is added to a place tag
- Place = neighbourhood/suburb/village/town
- + refugee_site=yes
- + refugee_site:XX=XX
-> but if I understand well, it’s not possible to tag a polygon with the tag place? if so this option is not relevant to map refugee_site as polygon.
also it not so easy to identify if the refugee site should be map as a neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s seems complicated to apply this to all context as she illustrated very well.
also it not so easy to identify if the refugee site should be map as a neighbourhood or a suburb or a village or a town. And as Jorieke said, it’s seems complicated to apply this to all context as she illustrated very well.
Option 2: The key refugee_site=yes is added to a landuse tag
- Landuse = residential
- + refugee_site=yes
- + refugee_site:XX=XX
-> But if I understand correctly, the use of landuse=residential is not always adapted to the refugee site (landuse=residential area, ideally, should only include areas that are primarily residential). Also it would be wrong to create a new residential area to delimit a refugee site already inside a larger residential area. Thus this option seems a bit problematic.
QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily have to be associated with place or landuse? And if we could have refugee_site=yes without any other tags ? in this case the limits cited above would no longer be constraining.
but if I understand you Joseph, this will be a problem for the rendering ?
but if I understand you Joseph, this will be a problem for the rendering ?
Option 3: use an existing main top-level key (from the listed options shared by Joseph)
My preference as Joseph and Oukasz would be for the
Amenity option, as it can apply as well as a node or a polygon, and fit better with the option for small refugee site.
- Amenity=refugee_site
- + refugee_site:XX=XX
QUESTION: I still have 2 questions. With this option could we still proposed the secondary tags refugee_site:XX=XX (for instance refugee_site:status=formal)? As those secondary tag are very important too as mentioned in the talk page and because the diversity of refugee_site is such that it’s important to be able to detail the characteristics of it.
Do we also have to add “refugee_site=yes” or it’s not necessary?
About rendering: for sure it’s good to take it into account, but I think it’s not a priority, the most important is to ensure a consistency in the way to map refugee site in OSM and to facilitate data extraction and data maintenance.
I have a more
practical question, as the proposition change a lot, what is best, create a new proposed feature page “refugee Site Location 3” or can I change the “refugee Site Location 2” page ?
Thank you for your participation
Have a great day,
Manon
Manon Viou
Coordinatrice projet Missing Maps
m_v...@cartong.org |
manon.viou
+33 (0)4 79 26 28 82 |
+33 (0)7 83889839
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
