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
On 10/11/22 22:36, Martin Koppenhoefer wrote:
sent from a phone
On 10 Nov 2022, at 12:31, Yves via Tagging 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
Jake Low wrote:
> I would not recommend adding a node tagged tourism=camp_site into this
> picture, as in my opinion it would be redundant with the site relation and
> a violation of the "one feature, one OSM element" guideline.
While this Approach would work well in OpenCampingMap, such
Like Adam, my experience is with backcountry camping sites located within
wilderness areas. These sites usually consist of a cluster of camp pitches and
related facilities like fire rings, pit toilets, etc. They do not generally
have well-defined geographic boundaries, so it would be
> a site relation is made for wind farm sites because the space
> between the turbines is sometimes used for other things (e.g. grazing),
> and not to include other elements such as the workers' parking, the
> restaurant where they eat and the shop they visit
>
My own mapping practice while canoe
Nov 12, 2022, 14:22 by li...@fuchsschwanzdomain.de:
> Mateusz Konieczny via Tagging wrote:
>
>> So
>> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
>> site relation is including nearby restaurant and shop?
>>
>
> Right!
>
>> That are not actually part of camp site?
Mateusz Konieczny via Tagging wrote:
> So
> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
> site relation is including nearby restaurant and shop?
Right!
> That are not actually part of camp site?
Wellm, they are not part of it geographicaly because the are located
Le 10.11.22 à 21:49, Sven Geggus a écrit :
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
first of all, you can't say both that the
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
Nov 10, 2022, 21:49 by li...@fuchsschwanzdomain.de:
> Yves via Tagging 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
Nov 10, 2022, 21:21 by li...@fuchsschwanzdomain.de:
> Marc_marc wrote:
>
>> taking one random exemple :
>> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
>> according to the parking name=*, the parking may be include in the
>> tourism=site_camp
>>
>
> Yes but this
sent from a phone
> On 10 Nov 2022, at 21:24, Sven Geggus wrote:
>
> Which is just plain wrong as they are not _only_.
you could have the sports centre and the camp site overlap, this way it
wouldn’t be _only_
A site relation doesn’t magically solve the uncertainty of exclusive vs. shared
sent from a phone
> On 10 Nov 2022, at 21:21, Sven Geggus wrote:
> All the sites in the above changeset would need one or more additional
> redundant tags like restaurant=yes on the main node or way if a site
> relation is no longer an option.
so a restaurant is part of the camp site, but
Ah?
Le 10 novembre 2022 21:09:47 GMT+01:00, Sven Geggus
a écrit :
>Yves wrote:
>
>> Instead of type=site + tourism=camp_site, type=site + site=camp_site would
>> be less prone to objections, maybe.
>
>Well, wiki states that site=something is not recommended anymore.
>
>Sven
>
How to map
Yves via Tagging 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
Martin Koppenhoefer wrote:
> multipolygons can solve any disjoint area problems, you only need a site
> relation if some members are nodes or linear ways or relations.
External objects of camp-sites are often node shaped.
Sven
--
"In my opinion MS is a lot better at making money than it is
Marc_marc wrote:
> taking one random exemple :
> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
> according to the parking name=*, the parking may be include in the
> tourism=site_camp
Yes but this is simply not as it is on the ground. The parking is not _part_
of the
Mateusz Konieczny via Tagging wrote:
> Yes, using site relation in addition to actual object breaks this rule
> and it is undesirable (and site relations in general are problematic).
Why do you think that "site relations in general are problematic"?
> Is there some reason why this camp sites
Marc_marc wrote:
>> Ignoring the principle (which is not absolute anyway)
>
> sorry but reading "No two campings", I can only agree
> that a campsite has only one tourism=camp_site tag and not 2
Shure. However I do not consider the site-relation a campsite itself but a
collection of other
Yves wrote:
> Instead of type=site + tourism=camp_site, type=site + site=camp_site would
> be less prone to objections, maybe.
Well, wiki states that site=something is not recommended anymore.
Sven
--
All bugs added by David S. Miller
Linux Kernel boot message from
Good point Martin
Le 10 novembre 2022 12:36:51 GMT+01:00, Martin Koppenhoefer
a écrit :
>
>
>sent from a phone
>
>> On 10 Nov 2022, at 12:31, Yves via Tagging wrote:
>>
>> Site relations are often used to models thing that aren't spatially joined,
>> like windfarms, universities...
>> I can
Le 10.11.22 à 12:26, Yves via Tagging a écrit :
it's reasonable to use them for campings in some corner cases where a
single area doesn't work.
taking one random exemple :
https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
according to the parking name=*, the parking may
sent from a phone
> On 10 Nov 2022, at 12:31, Yves via Tagging 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
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.
Yves
Le 10 novembre 2022 12:11:44 GMT+01:00, Mateusz Konieczny via
Yes, using site relation in addition to actual object breaks this rule
and it is undesirable (and site relations in general are problematic).
It would be also problem with type=site site=camp_sites and similar
trying to hide duplication.
Is there some reason why this camp sites cannot be mapped
Le 09.11.22 à 22:00, Sven Geggus a écrit :
Now a recent changeset discussion is questioning my whole approach because it
arguably violates the "One feature, one OSM element principle":
https://www.openstreetmap.org/changeset/126035627
this chanset is big, witch relation for ex ?
Ignoring
Instead of type=site + tourism=camp_site, type=site + site=camp_site would be
less prone to objections, maybe.
Regards,
Yves
Le 9 novembre 2022 22:00:23 GMT+01:00, Sven Geggus
a écrit :
>Hello,
>
>about a year ago I implemented support for site relations in OpenCampingMap.
>
>My
Hello,
about a year ago I implemented support for site relations in OpenCampingMap.
My announcement from back then is at:
https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/
Now a recent changeset discussion is questioning my whole approach because it
28 matches
Mail list logo
