Re: [Tagging] Relations of type=site + tourism=camp_site
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 use. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 not on the site but somewhere near, right? Or maybe you can give an example so we can better understand the problem? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 Create a relation and add type=site. In addition, the relation must have a main tag defining whatever feature the site relation describes. E.g. amenity=university, site=parking, site=piste, power=plant, etc. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 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. Last but not least, what I do consider bad practise and show them as a bug in my map is stuff like this: * More than one camp_site object added to a site relation * Using site-relations in cases a multipolygon is sufficient * Camp-sites that contain others (not part of this discussion) Regards Sven -- "The only thing we have to fear is fear itself" (Franklin D. Roosevelt) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 at making good operating systems" (Linus Torvalds, August 1997) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 camp-site but for visitors as well as the restaurant and shop. They are not stritly cusomers only like the enclosed area. > if someone think that the restaurant and the shop are also part of the > camp site, then it's easy to extend the area to include those. Which is just plain wrong as they are not _only_. Regards Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 cannot be mapped as areas > if someone is doing such detailed mapping? Of course there are. The thing is that objects outside (usually ways and nodes) might be part of a particular camp_site. E.g. when a sport-center and a camp_site are sharing there sanitary buildings. I did not implement the support for this in OpenCampingMap just for fun. I really do think that there is a need for this. 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. Regards Sven -- Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety (Benjamin Franklin) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 objects outside the main are or node which are pat of the site. Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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/vlan.c /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Railway tagging: detail key
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, 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 : old stuff before the (now de-facto in France) tracks=1 , to be deleted https://www.openstreetmap.org/changeset/111203619 mecanical edit annoncement was made on talk-fr for France Others values in France 'll be checkec/fixed by hand (I see some missuse for description) Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Railway tagging: detail key
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 : old stuff before the (now de-facto in France) tracks=1 , to be deleted https://www.openstreetmap.org/changeset/111203619 mecanical edit annoncement was made on talk-fr for France Others values in France 'll be checkec/fixed by hand (I see some missuse for description) Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - deposit rings
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 proposal here: https://wiki.openstreetmap.org/wiki/Proposed_features/deposit_rings Please discuss the proposal on the discussion page in the wiki and on these mailing list, if you want to. Are there similar things in your country? Please mention it. Regards Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 easily imagine it's reasonable to use them for campings in some corner >> cases where a single area doesn't work. > > >multipolygons can solve any disjoint area problems, you only need a site >relation if some members are nodes or linear ways or relations. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 be include in the tourism=site_camp if someone think that the restaurant and the shop are also part of the camp site, then it's easy to extend the area to include those. and whatever the scope, I see no reason to fill in tourism=camp_site both as a node and as a relation ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 doesn't work. multipolygons can solve any disjoint area problems, you only need a site relation if some members are nodes or linear ways or relations. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 Tagging a écrit : >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 as areas >if someone is doing such detailed mapping? > >or map operator of a toilet or extra features? > > >Nov 9, 2022, 22:00 by li...@fuchsschwanzdomain.de: > >> 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 >> arguably violates the "One feature, one OSM element principle": >> >> https://www.openstreetmap.org/changeset/126035627 >> >> Ignoring the principle (which is not absolute anyway) in this case and >> adding a relation of type=site + tourism=camp_site containing the actual >> tourism=camp_site object as a member does solve the problem thus I would go >> for doing just this as I did a year ago. >> >> Obviously others seem to differ here. >> >> Currently the above changeset breaks my map regarding those campsites where >> the tourism=camp_site tag has been removed from the site relation. >> >> External features are no longer shown :( >> >> So how to resolve this problem? >> >> campsites with external features (e.g. sanitary facilities used by a >> campsite and a sport-center) do exist in the wild and they usually do also >> have on-the-ground objects (way, node, polygon-relation) where no other tag >> than tourism=camp_site does make sense. >> >> What do you think? >> >> Sven >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 as areas if someone is doing such detailed mapping? or map operator of a toilet or extra features? Nov 9, 2022, 22:00 by li...@fuchsschwanzdomain.de: > 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 > arguably violates the "One feature, one OSM element principle": > > https://www.openstreetmap.org/changeset/126035627 > > Ignoring the principle (which is not absolute anyway) in this case and > adding a relation of type=site + tourism=camp_site containing the actual > tourism=camp_site object as a member does solve the problem thus I would go > for doing just this as I did a year ago. > > Obviously others seem to differ here. > > Currently the above changeset breaks my map regarding those campsites where > the tourism=camp_site tag has been removed from the site relation. > > External features are no longer shown :( > > So how to resolve this problem? > > campsites with external features (e.g. sanitary facilities used by a > campsite and a sport-center) do exist in the wild and they usually do also > have on-the-ground objects (way, node, polygon-relation) where no other tag > than tourism=camp_site does make sense. > > What do you think? > > Sven > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Street parking revision
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 schrieb Robert Skedgell: 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 with accessibility to know that it is potentially narrow, in the door zone, may have charging cables as trip hazards, etc. On 07/11/2022 11:37, Alex wrote: Hey all, over the past few weeks, a group of mappers has been working on a proposal to improve the mapping of parking lanes and parking spaces along streets. Considerations and discussions about this have already arisen in the past among street parking mappers, and now a proposal has been prepared. The goal of this proposal is to deprecate and replace the parking:lane=* and parking:condition=* schema for mapping street parking spaces. The existing schema has some weaknesses and is unnecessarily complicated and therefore unattractive for many mappers. Above all, in many ways it differs from today's OSM conventions. The proposed new schema is intended to be easier and more logical to apply. The new schema follows established OSM conventions more closely. It harmonises tagging of parking spaces mapped on the centerline as an attribute of a street with parking spaces mapped as a separate feature. It also reflects aspects of a data migration process. For details, see the proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/street_parking_revision It is quite extensive, as it covers and reforms all aspects of the previous schema and closes some further gaps. Best regards Alex ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
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 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 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Street parking revision
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 with accessibility to know that it is potentially narrow, in the door zone, may have charging cables as trip hazards, etc. On 07/11/2022 11:37, Alex wrote: Hey all, over the past few weeks, a group of mappers has been working on a proposal to improve the mapping of parking lanes and parking spaces along streets. Considerations and discussions about this have already arisen in the past among street parking mappers, and now a proposal has been prepared. The goal of this proposal is to deprecate and replace the parking:lane=* and parking:condition=* schema for mapping street parking spaces. The existing schema has some weaknesses and is unnecessarily complicated and therefore unattractive for many mappers. Above all, in many ways it differs from today's OSM conventions. The proposed new schema is intended to be easier and more logical to apply. The new schema follows established OSM conventions more closely. It harmonises tagging of parking spaces mapped on the centerline as an attribute of a street with parking spaces mapped as a separate feature. It also reflects aspects of a data migration process. For details, see the proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/street_parking_revision It is quite extensive, as it covers and reforms all aspects of the previous schema and closes some further gaps. Best regards Alex ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
