On 11/11/22 23:25, Casper Kersten wrote:
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.
Local councils operate some campsites here, they also operate the library, community centre, town hall ...
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.
Some campsites registration area/desk/office is some distance from the campsite itself.
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
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging