Nov 10, 2022, 21:49 by li...@fuchsschwanzdomain.de: > Yves via Tagging <tagging@openstreetmap.org> wrote: > >> Site relations are often used to models thing that aren't spatially >> joined, like windfarms, universities... I can easily imagine it's >> reasonable to use them for campings in some corner cases where a single >> area doesn't work. >> > > Yes, let me clarify this with an example: > > E.g. This site has a working site relation (without tourism=camp_site > removed): > > https://opencampingmap.org/#15/49.0815/7.9123/1/1/bef/node/3824691120 > > The camp_site node is https://www.openstreetmap.org/node/3824691120 > Site relation is https://www.openstreetmap.org/relation/13009876 > > While it is currently tagged toilets=yes and openfire=yes this is not > mandatory because evaluating the corresponding site relation will give us a > toilet and a fireplace. > > So what I do with site relations here is basically the same I do with > camp_site areas. With areas I check if any supported object is inside the > area (spatial join) and assume that this is a feature of this particular > camp_site. > > With site-relations this is even easier as I can consider all objects > related to the site a feature of the camp-site in the relation. > > I think this is elegant especially in comparison to the alternatives > suggested here like expanding the campsite polygon into areas open to the > general public like reception desks, restaurants or even toilets also used > by other facilities like sport-centers. > obviously camp site should not be fakely expanded to cover nearby restaurants what about automatically detecting nearby restaurants/toilets and so on? rater than listing them manually with site relation (optionally, check operator tag - that would apply only in cases where there are multiple camp sites or other objects each with access=customers objects)
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
