[Tagging] Relations of type=site + tourism=camp_site

[Warin]

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 at openstreetmap.org>:
>
>
>
>
>     Nov 10, 2022, 21:49 by lists at fuchsschwanzdomain.de:
>
>         Yves via Tagging <tagging at 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 at openstreetmap.org
>     https://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20221212/9657b51e/attachment.htm>