Thanks, that should make mapping street parking in my local area much
easier and more consistent.
Where parking=on_kerb or parking=half_on_kerb are used alongside a
separately mapped sidewalk or cycle track, should there be a tag on that
way as well? It could be useful to routers concerned wit
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 the
I think such limitations can be mapped sufficiently by using "width",
"maxwidth:physical" or "wheelchair" etc. For hazards like dooring zones,
there are already experiments with "hazard[:bicycle]" or "danger", but
more documentation or a proposal on this might be useful.
Am 10.11.22 um 08:59
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 a
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 Ta
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
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 b
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
Hi everyone,
I propose the new key deposit_ring to indicate if a waste basket is
equipped with a deposit ring, which number began to grow in Germany some
years ago. These are present at (central situated) waste baskets in over
one hundred German municipalities nowadays.
You can read the pro
Le 09.11.22 à 15:20, Marc_marc a écrit :
Hello,
Le 09.11.22 à 10:59, Nathan Case a écrit :
The key is predominantly used in France (77.6% of uses [3])
no idea.
forwarded/translated to talk-fr + 2 changeset comment
feedback from the main (if not the only) contributor of this tag in
France :
Thanks (merci!) for your response and for looking into this Marc.
Since it seems a large part of the usage of this key will be reverted,
I'll leave it as undocumented for now.
Nathan
On 10/11/2022 15:32, Marc_marc wrote:
Le 09.11.22 à 15:20, Marc_marc a écrit :
Hello,
Le 09.11.22 à 10:59,
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 /usr/src/linux/net/8021q/
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 objec
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 ca
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
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 a
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 examp
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
Cre
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 is
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
20 matches
Mail list logo
