Site relations are usually completely redundant if you just tag an operator=* tag. A tourism=camp_site closed way or multipolygon is, of course, a camp site, and a shop or parking area on or belonging to that camp site should get an operator=* tag with the same tag value as the name or operator of the camp site.
Grouping the tourism=camp_site area and all objects related to that camp site in a site relation and calling that a camp site as a whole is a clear violation of the One feature, one OSM element guideline, as the tourism=camp_site is already the element for the camp site and the site relation would unnecessarily duplicate that. Op vr 11 nov. 2022 om 10:55 schreef Mateusz Konieczny via Tagging < tagging@openstreetmap.org>: > > > > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
