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
<[email protected]>:
Nov 10, 2022, 21:49 by [email protected]:
Yves via Tagging <[email protected]> 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
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
