Re: [Tagging] Tagging method of amenities at camp_sites
On Mar 30, 2015 11:05 PM, "Bryce Nesbitt" wrote: > > On Mon, Mar 30, 2015 at 2:51 PM, fly wrote: >> >> Am 30.03.2015 um 23:35 schrieb John F. Eldredge: >> > It's about time that renderers started supporting semicolon-delimited lists. Splitting apart a delimited string is a trivial programming task. I know, having worked as a programmer for the last 29 years. > > > It's not necessarily so trivial. For example, the main OSM style is run by backend that has surprising limits due to database design. Not to mention that maintainability is a mess. And in both the site examples in this thread as well as ref=* to describe routes on ways are both problems that are made stupidly trivial with relations. And I know I sound like a broken record but it's time to kill the "ref=* on ways to mean routes" dinosaur like Linux killed ext after ext3 came out... in both cases, nothing rational should be depending on the old method anymore. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Mar 29, 2015 1:28 AM, "David Bannon" wrote: > > On Sat, 2015-03-28 at 21:57 -0700, Bryce Nesbitt wrote: > > wrote: > > Just a note about using semicolon-delimited lists. Most > > renderers do not handle such lists very well so a tag like the > > following: > > amenity=bar;restaurant;picnic_table;sanitary_dump_station > > > Most rendering will show nothing for such tagging. If you tag like > > that, few people will ever see it. > > > So this is, IMHO, the crucial question. I've been too scared to ask it > in fear of being accused to Tagging for the Render. Is the > [SomeAmenityValue=yes] preferred by the rendered over a delimited list ? > Can we get that authoritatively ? A reference ? Try Roman Nose State Park or Mingo RV Park in Oklahoma. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Tue, Mar 31, 2015 at 1:40 AM, Martin Koppenhoefer wrote: > +1, often mappers use semikolon separated lists on the same object for what > should actually be more than one object (in cases where a main tag has > multiple values). This is not working. But it is normally no problem to use > multivalues for properties (e.g. cuisine=turkish;italian). Rendering support is generally not there for semicolons in values either, even in simple cases like shop=shoes;clothes. For better or worse, many mappers use semicolons in ways that cause their features not to be rendered at all. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
2015-03-31 8:08 GMT+02:00 Dave Swarthout : > amenity=toilets;drinking_water > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > Yes, good information. There is much ambiguity in that example if the > tagging is not done carefully and properly. +1, often mappers use semikolon separated lists on the same object for what should actually be more than one object (in cases where a main tag has multiple values). This is not working. But it is normally no problem to use multivalues for properties (e.g. cuisine=turkish;italian). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
amenity=toilets;drinking_water fee=no opening_hours=24/7 toilets:position=seated;urinal Yes, good information. There is much ambiguity in that example if the tagging is not done carefully and properly. On Tue, Mar 31, 2015 at 11:03 AM, Bryce Nesbitt wrote: > On Mon, Mar 30, 2015 at 2:51 PM, fly wrote: > >> Am 30.03.2015 um 23:35 schrieb John F. Eldredge: >> > It's about time that renderers started supporting semicolon-delimited >> lists. Splitting apart a delimited string is a trivial programming task. I >> know, having worked as a programmer for the last 29 years. > > > It's not necessarily so trivial. For example, the main OSM style is run > by backend that has surprising limits due to database design. > However a rendering engine that's iterating through objects could take: > > amenity=toilets;drinking_water > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > > And expand it to: > > amenity=toilets > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > amenity=drinking_water > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > > But quickly you have tag pollution and it is not clear semantically which > tag is the "main tag", and which tags refer to which amenity. > Somewhat clearer is: > > amenity=toilets > drinking_water=yes > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > > Which would expand to: > > amenity=toilets > fee=no > opening_hours=24/7 > toilets:position=seated;urinal > > amenity=drinking_water > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Mon, Mar 30, 2015 at 2:51 PM, fly wrote: > Am 30.03.2015 um 23:35 schrieb John F. Eldredge: > > It's about time that renderers started supporting semicolon-delimited > lists. Splitting apart a delimited string is a trivial programming task. I > know, having worked as a programmer for the last 29 years. It's not necessarily so trivial. For example, the main OSM style is run by backend that has surprising limits due to database design. However a rendering engine that's iterating through objects could take: amenity=toilets;drinking_water fee=no opening_hours=24/7 toilets:position=seated;urinal And expand it to: amenity=toilets fee=no opening_hours=24/7 toilets:position=seated;urinal amenity=drinking_water fee=no opening_hours=24/7 toilets:position=seated;urinal But quickly you have tag pollution and it is not clear semantically which tag is the "main tag", and which tags refer to which amenity. Somewhat clearer is: amenity=toilets drinking_water=yes fee=no opening_hours=24/7 toilets:position=seated;urinal Which would expand to: amenity=toilets fee=no opening_hours=24/7 toilets:position=seated;urinal amenity=drinking_water ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
I asked what the OSMAnd developers prefer but have not yet had an answer. On their forum by the way, works well ! David On Tue, 2015-03-31 at 07:11 +0700, Dave Swarthout wrote: > It's about time that renderers started supporting semicolon-delimited > lists. Splitting apart a delimited string is a trivial programming > task. I know, having worked as a programmer for the last 29 years. > +1 > > > Speaking as an ex-programmer, I completely agree > > > PHP, and other languages, actually have a built-in function to do > that: split, explode, etc. > > > Regds > > > Dave > > On Tue, Mar 31, 2015 at 4:35 AM, John F. Eldredge > wrote: > It's about time that renderers started supporting > semicolon-delimited lists. Splitting apart a delimited string > is a trivial programming task. I know, having worked as a > programmer for the last 29 years. > > > > On March 28, 2015 11:09:10 PM CDT, Dave Swarthout > wrote: > Just a note about using semicolon-delimited lists. > Most renderers do not handle such lists very well so a > tag like the following: > > amenity=bar;restaurant;picnic_table;sanitary_dump_station > > > might not show you all of the amenities. There have > been many discussions about this issue on this list > and elsewhere > > On Sun, Mar 29, 2015 at 9:39 AM, David Bannon > wrote: > On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis > wrote: > > > If I am on a large campsite I want to use > "the map" to find my way to > > all amenities. If you have put everything on > 1 node it's a pretty > > useless map, not ? > > Agree in principle Marc but don't think its > always practical. I have > been to many camp grounds that are too big to > walk around and bad > manners to drive (apparently aimlessly) > around. Many National Park > toilets are drop toilets and, for obviously > reasons need to be moved. > Fireplaces are often quite impromptu, we are > marking they are allowed, > not where they are. > > I agree it would be nice to be able to zoom in > and see where fixed > things are, highly desirable for the people > there on site. But people > planning a trip, they just want to know fire > places and toilets are > there, somewhere. Lets help the second group > and then, if we can, the > first. > > David > > > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > > > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > __ > > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > 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] Tagging method of amenities at camp_sites
It's about time that renderers started supporting semicolon-delimited lists. Splitting apart a delimited string is a trivial programming task. I know, having worked as a programmer for the last 29 years. +1 Speaking as an ex-programmer, I completely agree PHP, and other languages, actually have a built-in function to do that: split, explode, etc. Regds Dave On Tue, Mar 31, 2015 at 4:35 AM, John F. Eldredge wrote: > It's about time that renderers started supporting semicolon-delimited > lists. Splitting apart a delimited string is a trivial programming task. I > know, having worked as a programmer for the last 29 years. > > > > On March 28, 2015 11:09:10 PM CDT, Dave Swarthout > wrote: >> >> Just a note about using semicolon-delimited lists. Most renderers do not >> handle such lists very well so a tag like the following: >> >> amenity=bar;restaurant;picnic_table;sanitary_dump_station >> >> might not show you all of the amenities. There have been many discussions >> about this issue on this list and elsewhere >> >> On Sun, Mar 29, 2015 at 9:39 AM, David Bannon >> wrote: >> >>> On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis wrote: >>> >>> > If I am on a large campsite I want to use "the map" to find my way to >>> > all amenities. If you have put everything on 1 node it's a pretty >>> > useless map, not ? >>> >>> Agree in principle Marc but don't think its always practical. I have >>> been to many camp grounds that are too big to walk around and bad >>> manners to drive (apparently aimlessly) around. Many National Park >>> toilets are drop toilets and, for obviously reasons need to be moved. >>> Fireplaces are often quite impromptu, we are marking they are allowed, >>> not where they are. >>> >>> I agree it would be nice to be able to zoom in and see where fixed >>> things are, highly desirable for the people there on site. But people >>> planning a trip, they just want to know fire places and toilets are >>> there, somewhere. Lets help the second group and then, if we can, the >>> first. >>> >>> David >>> > >>> >>> >>> >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> >> >> -- >> Dave Swarthout >> Homer, Alaska >> Chiang Mai, Thailand >> Travel Blog at http://dswarthout.blogspot.com >> >> -- >> >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >> > -- > John F. Eldredge -- j...@jfeldredge.com > "Darkness cannot drive out darkness; only light can do that. Hate cannot > drive out hate; only love can do that." -- Martin Luther King, Jr. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Am 29.03.2015 um 11:27 schrieb Bryce Nesbitt: > On Sun, Mar 29, 2015 at 1:37 AM, Warin <61sundow...@gmail.com> wrote: > >> What if you do know details .. but not the exact location? Still place a >> node somewheres? >> > > How about at that point you go visit the site, and map based on that visit. > > OSM has a ten year history: have a look at existing convention. This > tagging list has only moderate influence > on anything that happens in OSM-land. +1 I wonder that nobody so far did spell out a warning about adding information from websites. The simple key website=* is ok, but every information like address, prizes and all the amenities is most of the time not usable due to license problems. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Am 30.03.2015 um 23:35 schrieb John F. Eldredge: > It's about time that renderers started supporting semicolon-delimited lists. > Splitting apart a delimited string is a trivial programming task. I know, > having worked as a programmer for the last 29 years. +1 cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
It's about time that renderers started supporting semicolon-delimited lists. Splitting apart a delimited string is a trivial programming task. I know, having worked as a programmer for the last 29 years. On March 28, 2015 11:09:10 PM CDT, Dave Swarthout wrote: > Just a note about using semicolon-delimited lists. Most renderers do > not > handle such lists very well so a tag like the following: > > amenity=bar;restaurant;picnic_table;sanitary_dump_station > > might not show you all of the amenities. There have been many > discussions > about this issue on this list and elsewhere > > On Sun, Mar 29, 2015 at 9:39 AM, David Bannon > > wrote: > > > On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis wrote: > > > > > If I am on a large campsite I want to use "the map" to find my way > to > > > all amenities. If you have put everything on 1 node it's a pretty > > > useless map, not ? > > > > Agree in principle Marc but don't think its always practical. I have > > been to many camp grounds that are too big to walk around and bad > > manners to drive (apparently aimlessly) around. Many National Park > > toilets are drop toilets and, for obviously reasons need to be > moved. > > Fireplaces are often quite impromptu, we are marking they are > allowed, > > not where they are. > > > > I agree it would be nice to be able to zoom in and see where fixed > > things are, highly desirable for the people there on site. But > people > > planning a trip, they just want to know fire places and toilets are > > there, somewhere. Lets help the second group and then, if we can, > the > > first. > > > > David > > > > > > > > > > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- John F. Eldredge -- j...@jfeldredge.com "Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that." -- Martin Luther King, Jr.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sun, Mar 29, 2015 at 1:37 AM, Warin <61sundow...@gmail.com> wrote: > What if you do know details .. but not the exact location? Still place a > node somewheres? > How about at that point you go visit the site, and map based on that visit. OSM has a ten year history: have a look at existing convention. This tagging list has only moderate influence on anything that happens in OSM-land. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On 29/03/2015 6:14 PM, Dave Swarthout wrote: On Sun, Mar 29, 2015 at 2:12 PM, Dave Swarthout mailto:daveswarth...@gmail.com>> wrote: But does having a JOSM preset that sets a tag bar=yes mean that the bar actually gets rendered, or is it just findable though a query you can make to OSMAnd or whatever? It all depends on which map or which renderer you're talking about does it not? I reckon it doesn't matter all that much as long as you can make assessments of the camp_site when you want them. Maybe the JOSM presets have (preexisting) wiki entries. On 29/03/2015 3:57 PM, Bryce Nesbitt wrote: Much cleaner tagging, and the way it's frequently done now, is a node or area with: amenity=camp_site bar=yes picnic_table=yes internet_access=wlan opening_hours=24/7 fee=$5 Now it's clear that the camp site is open 24/7 and costs $5, but nothing specific is said about the other amenities. If you know more about the bar, then you can create a separate node with all the details. But you maintain that putting a node when you don't know exactly where it should be is a no no, and now advise to place a node .. just because you know the opening_hours? What if you do know details .. but not the exact location? Still place a node somewheres? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sun, Mar 29, 2015 at 2:12 PM, Dave Swarthout wrote: > But does having a JOSM preset that sets a tag bar=yes mean that the bar > actually gets rendered, or is it just findable though a query you can make > to OSMAnd or whatever? It all depends on which map or which renderer you're > talking about does it not? I reckon it doesn't matter all that much as long as you can make assessments of the camp_site when you want them. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
But does having a JOSM preset that sets a tag bar=yes mean that the bar actually gets rendered, or is it just findable though a query you can make to OSMAnd or whatever? It all depends on which map or which renderer you're talking about does it not? On Sun, Mar 29, 2015 at 1:39 PM, Bryce Nesbitt wrote: > On Sat, Mar 28, 2015 at 11:26 PM, David Bannon > wrote: > >> So this is, IMHO, the crucial question. I've been too scared to ask it >> in fear of being accused to Tagging for the Render. Is the >> [SomeAmenityValue=yes] preferred by the rendered over a delimited list ? >> Can we get that authoritatively ? A reference ? >> > > A dozen or more JOSM presets do it that way. That's as authoritative as > you're going to get in Open Street Map. > > > amenity=camp_site > > bar=yes > > picnic_table=yes > > internet_access=wlan > > opening_hours=24/7 > > fee=$5 > > > Cleaner and clearer. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, Mar 28, 2015 at 11:26 PM, David Bannon wrote: > So this is, IMHO, the crucial question. I've been too scared to ask it > in fear of being accused to Tagging for the Render. Is the > [SomeAmenityValue=yes] preferred by the rendered over a delimited list ? > Can we get that authoritatively ? A reference ? > A dozen or more JOSM presets do it that way. That's as authoritative as you're going to get in Open Street Map. > amenity=camp_site > bar=yes > picnic_table=yes > internet_access=wlan > opening_hours=24/7 > fee=$5 > Cleaner and clearer. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, 2015-03-28 at 21:57 -0700, Bryce Nesbitt wrote: > wrote: > Just a note about using semicolon-delimited lists. Most > renderers do not handle such lists very well so a tag like the > following: > amenity=bar;restaurant;picnic_table;sanitary_dump_station > Most rendering will show nothing for such tagging. If you tag like > that, few people will ever see it. So this is, IMHO, the crucial question. I've been too scared to ask it in fear of being accused to Tagging for the Render. Is the [SomeAmenityValue=yes] preferred by the rendered over a delimited list ? Can we get that authoritatively ? A reference ? > amenity=camp_site > bar=yes > picnic_table=yes > internet_access=wlan > opening_hours=24/7 > fee=$5 > Cleaner and clearer. David > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, Mar 28, 2015 at 9:09 PM, Dave Swarthout wrote: > Just a note about using semicolon-delimited lists. Most renderers do not > handle such lists very well so a tag like the following: > amenity=bar;restaurant;picnic_table;sanitary_dump_station > Most rendering will show nothing for such tagging. If you tag like that, few people will ever see it. It's also ambiguous tagging, as you won't know what the other tags refer to. For example: amenity=bar;restaurant;picnic_table;sanitary_dump_station;internet_access opening_hours=24/7 fee=$5 Makes it unclear what the bar's hours are. Much cleaner tagging, and the way it's frequently done now, is a node or area with: amenity=camp_site bar=yes picnic_table=yes internet_access=wlan opening_hours=24/7 fee=$5 Now it's clear that the camp site is open 24/7 and costs $5, but nothing specific is said about the other amenities. If you know more about the bar, then you can create a separate node with all the details. If the camp_site is a node, consider researching the true boundaries (if it has fixed boundaries) and making it an area instead. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Just a note about using semicolon-delimited lists. Most renderers do not handle such lists very well so a tag like the following: amenity=bar;restaurant;picnic_table;sanitary_dump_station might not show you all of the amenities. There have been many discussions about this issue on this list and elsewhere On Sun, Mar 29, 2015 at 9:39 AM, David Bannon wrote: > On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis wrote: > > > If I am on a large campsite I want to use "the map" to find my way to > > all amenities. If you have put everything on 1 node it's a pretty > > useless map, not ? > > Agree in principle Marc but don't think its always practical. I have > been to many camp grounds that are too big to walk around and bad > manners to drive (apparently aimlessly) around. Many National Park > toilets are drop toilets and, for obviously reasons need to be moved. > Fireplaces are often quite impromptu, we are marking they are allowed, > not where they are. > > I agree it would be nice to be able to zoom in and see where fixed > things are, highly desirable for the people there on site. But people > planning a trip, they just want to know fire places and toilets are > there, somewhere. Lets help the second group and then, if we can, the > first. > > David > > > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis wrote: > If I am on a large campsite I want to use "the map" to find my way to > all amenities. If you have put everything on 1 node it's a pretty > useless map, not ? Agree in principle Marc but don't think its always practical. I have been to many camp grounds that are too big to walk around and bad manners to drive (apparently aimlessly) around. Many National Park toilets are drop toilets and, for obviously reasons need to be moved. Fireplaces are often quite impromptu, we are marking they are allowed, not where they are. I agree it would be nice to be able to zoom in and see where fixed things are, highly desirable for the people there on site. But people planning a trip, they just want to know fire places and toilets are there, somewhere. Lets help the second group and then, if we can, the first. David > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Have you noticed how few people participate in votes and tagging discussions? The wiki vote process relates to the wiki. OSM has an open tagging system, and many users never read or interact with the wiki. Success of a wiki vote may or may not lead to a change in mapping behaviour. On Sat, Mar 28, 2015 at 1:59 PM, Jan van Bekkum wrote: > So what is the voting for then: > http://wiki.openstreetmap.org/wiki/Proposal_process? > > 1) There's no such thing as *approved*. >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
So what is the voting for then: http://wiki.openstreetmap.org/wiki/Proposal_process? On Sat, Mar 28, 2015 at 9:57 PM Bryce Nesbitt wrote: > On Sat, Mar 28, 2015 at 1:16 PM, Jan van Bekkum > wrote: > >> >>> It means that you create new tags for objects for which approved tags >>> already exist, such as amenity=shower and leisure=swimming pool, this is >>> not a good practice. >>> >> > 1) There's no such thing as *approved*. > 2) The tagging style is common practice > 3) It lets you tag things that don't exist, such as the 2,939 uses of > "swimming_pool=no", and the 9,232 uses of "drinking_water=no". Tagging of > the lack of water is crucial to backpackers and presumably overlanders. > 4) It lets you readily map campsites based on a printed park service map, > where the location and amenities are clear, but you've never visited. > > There is not one style of mapping. Trying to cram everything into one > grand scheme does not work (example: trying to cram sewage disposal and > recycling into the waste disposal tag). > > > ___ > 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] Tagging method of amenities at camp_sites
On Sat, Mar 28, 2015 at 1:16 PM, Jan van Bekkum wrote: > >> It means that you create new tags for objects for which approved tags >> already exist, such as amenity=shower and leisure=swimming pool, this is >> not a good practice. >> > 1) There's no such thing as *approved*. 2) The tagging style is common practice 3) It lets you tag things that don't exist, such as the 2,939 uses of "swimming_pool=no", and the 9,232 uses of "drinking_water=no". Tagging of the lack of water is crucial to backpackers and presumably overlanders. 4) It lets you readily map campsites based on a printed park service map, where the location and amenities are clear, but you've never visited. There is not one style of mapping. Trying to cram everything into one grand scheme does not work (example: trying to cram sewage disposal and recycling into the waste disposal tag). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
> > > > What if I know the camp site has a showers, a swimming pool and a dump > station, but I don't know where on the site they are? > Thus: > > *tourism=camp_site* > *showers=yes* > *swimming_pool=yes* > *dump_station=yes* > > > It means that you create new tags for objects for which approved tags > already exist, such as amenity=shower and leisure=swimming pool, this is > not a good practice. > >> >> ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, Mar 28, 2015 at 2:27 AM, Jan van Bekkum wrote: > Bryce > This is not the right example. All tags in your example are attributes > that belong to the camp_site, no need for extra nodes; you are fully > correct there. > > What I am talking about is multiple namespace tags in a single node: > tourism=camp_site > amenity=restaurant;shower;bar;swimming_pool > shop=convenience;supermarket > What if I know the camp site has a showers, a swimming pool and a dump station, but I don't know where on the site they are? Thus: *tourism=camp_site* *showers=yes* *swimming_pool=yes* *dump_station=yes* What happens if the opening hours of restaurant and bar are different? What > happens if I can pay with credit card for the campsite, but not for the > restaurant? No way to tag that. > Once you map to that level of detail, make individual nodes. *Mapping happens in layers: often starting with a fairly basic representation, then moving toward more detail.* Forcing people to insert fake geometry to represent amenities is a terrible solution. Forcing people to complicated mapping schemes has a good chance of reducing map contributions. But as I said nothing needs to be done here: people have already mapped thousands of camp sites using the amenity listing style above. It's not new. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
> Am 28.03.2015 um 07:17 schrieb Jan van Bekkum : > > g that clearly isn't the real shape ( a small square or a circle) and put all > nodes within it. a square clearly reduces impact on the db, as 4 nodes are sufficient, from that point of view, a triangle is even better ;-) Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Conclusion for my own mapping efforts from the discussion so far: start with stacked amenities until you know something about the campsite topology, then make nodes/polygons per amenity. On Sat, Mar 28, 2015 at 12:58 PM Martin Koppenhoefer wrote: > > > > > > Am 28.03.2015 um 12:26 schrieb Marc Gemis : > > > > If I am on a large campsite I want to use "the map" to find my way to > all amenities. If you have put everything on 1 node it's a pretty useless > map, not ? > > > +1, IMHO the ideal mapping should be an area for the camp site, and > features should be mapped inside this area as objects on their own (i.e. no > need to repeat those as attributes on the camp site). > A specialized camping map could see from the data which features are > available on a certain site (because this information is spatially > available) > > On the other hand this requires some processing / advanced querying and > might be too expensive for general maps, so a basic scheme with rough site > types for the camp site object ((1-2 attributes should be sufficient) seem > reasonable as well. > > Cheers > Martin > ___ > 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] Tagging method of amenities at camp_sites
> Am 27.03.2015 um 17:21 schrieb Bryce Nesbitt : > > Site relations are clearly the best solution when micro-mapping. site relations are only adding value when you want to connect objects that are not already spatially connected, or when you want to use fancy roles (eg this parking, not on the site itself, is for the customers of this site, or this is the ticket office for this site) > > In simple cases a few attributes on a node does just fine, gets the job done, > and causes no problems. > +1, although I'd normally prefer any approximation of an area to a (dimensionless) node > A huge downside of #4 is for armchair mapping. I may have access to a > website for a caravan_site, and know that if offers showers, > laundry and a dump station. But I have no idea where on the site they are. > All I can really do is tag those amenities as attributes. yes, if you don't know what you are mapping the result will hardly be good Cheers Martin___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
> Am 28.03.2015 um 12:26 schrieb Marc Gemis : > > If I am on a large campsite I want to use "the map" to find my way to all > amenities. If you have put everything on 1 node it's a pretty useless map, > not ? +1, IMHO the ideal mapping should be an area for the camp site, and features should be mapped inside this area as objects on their own (i.e. no need to repeat those as attributes on the camp site). A specialized camping map could see from the data which features are available on a certain site (because this information is spatially available) On the other hand this requires some processing / advanced querying and might be too expensive for general maps, so a basic scheme with rough site types for the camp site object ((1-2 attributes should be sufficient) seem reasonable as well. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Sat, Mar 28, 2015 at 1:32 AM, Bryce Nesbitt wrote: > The advantage of the single node approach is you can make a list of camp > sites and their amenities really easily, > and you can click once on a campsite tag, and understand what's there. > I thought we collected data to create maps, not to compile listings. :-) On one hand you see that people are started to map indoor stuff, with the correct positions of toilets etc. on each floor and here I read that you should put everything on one node ? If I am on a large campsite I want to use "the map" to find my way to all amenities. If you have put everything on 1 node it's a pretty useless map, not ? regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Bryce, This is not the right example. All tags in your example are attributes that belong to the camp_site, no need for extra nodes; you are fully correct there. What I am talking about is multiple namespace tags in a single node: tourism=camp_site amenity=restaurant;shower;bar;swimming_pool shop=convenience;supermarket What happens if the opening hours of restaurant and bar are different? What happens if I can pay with credit card for the campsite, but not for the restaurant? No way to tag that. Whatever we choose no new tagging proposal is needed for this. Option 1 (stacked namespace tags) ,3 (multiple nodes) and 4 (multiple nodes with site relation) can all be done with what exists today. I only ask of a choice between the options. Regards, Jan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Fri, Mar 27, 2015 at 11:17 PM, Jan van Bekkum wrote: > What do I see on the map when I use the stacked amenity model? > Tagging for today's rendering is hazardous. The stacked amenity model is quite common. Nothing seems broken about it at all. For example: http://www.openstreetmap.org/node/1225292499/history There are thousands like that. > If I (roughly) know the camping perimeter I can place the amenities as > nodes or buildings within them. Having three nodes close together but not > at the exact location is not worse than having a single stacked node which > isn't a the exact place either. If you don't know the perimeter at all draw > something that clearly isn't the real shape ( a small square or a circle) > and put all nodes within it. > Sometimes the amenity you want to map can't even be assigned a proper geometry (for example internet_access=wifi). Creating fake geometry in order to get nodes to render would push things in a really bad direction. Next we'd be talking about how many meters apart to space fake nodes so they render properly. I think the proper tagging proposal here is: no tagging proposal at all. It's all working just fine. > A search in OsmAnd will give me the campsite in all cases, but it cannot always show all tags below it Then speak to the OsmAnd developers abound rendering known amenities highway shield style: Don't tag for OsmAnd. Tag for tagability. Tag for ease of understanding by non-English speakers. Tag for data preservation. But don't tag for a particular rendering. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
What do I see on the map when I use the stacked amenity model? A campsite symbol with a restaurant below it or a restaurant symbol with a campsite below it? A search in OsmAnd will give me the campsite in all cases, but it cannot always show all tags below it, so I don't know all amenities by looking at the node. If I have separate nodes I always see them all. If I (roughly) know the camping perimeter I can place the amenities as nodes or buildings within them. Having three nodes close together but not at the exact location is not worse than having a single stacked node which isn't a the exact place either. If you don't know the perimeter at all draw something that clearly isn't the real shape ( a small square or a circle) and put all nodes within it. On Sat, Mar 28, 2015 at 1:34 AM Bryce Nesbitt wrote: > On Fri, Mar 27, 2015 at 2:24 PM, Warin <61sundow...@gmail.com> wrote: > >> OR .. you could place each node of the separate features close together >> with a fixme tag on them ... >> This way you don't need two systems for tagging the same thing. And it >> makes it easier for a mapper to move them to the correct location when they >> are found. And it conveys the information and being spacialy close they >> indicate that the loctions are not absolutely correct. ANd the renders >> don't need to recognise two different systems for the same thing. >> > > The advantage of the single node approach is you can make a list of camp > sites and their amenities really easily, > and you can click once on a campsite tag, and understand what's there. > > Look at camp and caravan sites in New Zealand for examples of full on > "ammenity" style tagging. > > -- > I think piling a bunch of nodes in the wrong place is not particularly > kind to the next mapper, or the reader. > ___ > 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] Tagging method of amenities at camp_sites
On Fri, Mar 27, 2015 at 2:24 PM, Warin <61sundow...@gmail.com> wrote: > OR .. you could place each node of the separate features close together > with a fixme tag on them ... > This way you don't need two systems for tagging the same thing. And it > makes it easier for a mapper to move them to the correct location when they > are found. And it conveys the information and being spacialy close they > indicate that the loctions are not absolutely correct. ANd the renders > don't need to recognise two different systems for the same thing. > The advantage of the single node approach is you can make a list of camp sites and their amenities really easily, and you can click once on a campsite tag, and understand what's there. Look at camp and caravan sites in New Zealand for examples of full on "ammenity" style tagging. -- I think piling a bunch of nodes in the wrong place is not particularly kind to the next mapper, or the reader. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Fri, 2015-03-27 at 14:07 +, Jan van Bekkum wrote: > It is a bit of a philosophical question: do you prefer a placeholder > or a polygon of which you don't know how correct it is, for example a > forest behind the campsite that may or may not be part of the > campground. In natural surroundings, a place holder node is the lesser of two evils. To mark an arbitrary poly implies camping within is somehow better than outside. And that is totally misleading. But a single node cannot carry the #4 model associating different features or constraints. So a very little polygon ? One that implies its a 'pitch' rather than a campground ? It says "I camped right here". David > > > On Fri, Mar 27, 2015 at 1:57 PM Marc Gemis > wrote: > In many cases you will be able to determine the area from the > aerial images (thinking of Western European campsites). > I assume that in the campsites you visited, the actual area > was rather fuzzy and that the exact area will never been > known, not ? OSM has no solution for fuzzy areas anyhow. > > > Is it difficult to obtain an approximation of the area when > you already go through the effort to position all the > amenities as individual nodes ? > you can always leave a note or fixme tag to indicate that the > shape has to be established. > > > just my .5 cents > > > regards > > > m > > On Fri, Mar 27, 2015 at 12:37 PM, Jan van Bekkum > wrote: > So if you don't know the real shape of the polygon it > would be best to create a placeholder polygon (like a > circle - it will be clear that it is a placeholder) > and put all amenities inside it until the real shape > is known. > > > On Fri, Mar 27, 2015 at 10:33 AM Marc Gemis > wrote: > > Overpass understands this. When I look for all > toilets in the "Zoo Antwerpen" with [1], I > only find toilets in that Zoo > > > regards > > > m > > > [1] http://overpass-turbo.eu/s/8qL > > On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis > wrote: > > OK, I did not know that ! Is > this "is-in-polygon" test > something that > is already being done ? > Examples ? > > > Nominatim that adds the address of the > building to the POI is an example of a > similar test / algorithm. > Sorry, don't know any other examples. > But it just makes sense that you do > not have to define inclusion of > something when you can determine that > from it's position. > > > I also only know 1 website that > supports the site relation, the > geschichtskarte for historical items > > > regards > > > m > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > 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] Tagging method of amenities at camp_sites
On 28/03/2015 3:21 AM, Bryce Nesbitt wrote: Site relations are clearly the best solution when micro-mapping. But this is not a one size fits all choice. There are many mappers, tools, and places that are not ready for that level of complexity. We're lucky to get many campsites mapped at all. In simple cases a few attributes on a node does just fine, gets the job done, and causes no problems. A huge downside of #4 is for armchair mapping. I may have access to a website for a caravan_site, and know that if offers showers, laundry and a dump station. _/ But I have no idea where on the site they are./_ All I can really do is tag those amenities as attributes. OR .. you could place each node of the separate features close together with a fixme tag on them ... This way you don't need two systems for tagging the same thing. And it makes it easier for a mapper to move them to the correct location when they are found. And it conveys the information and being spacialy close they indicate that the loctions are not absolutely correct. ANd the renders don't need to recognise two different systems for the same thing. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Site relations are clearly the best solution when micro-mapping. But this is not a one size fits all choice. There are many mappers, tools, and places that are not ready for that level of complexity. We're lucky to get many campsites mapped at all. In simple cases a few attributes on a node does just fine, gets the job done, and causes no problems. A huge downside of #4 is for armchair mapping. I may have access to a website for a caravan_site, and know that if offers showers, laundry and a dump station. * But I have no idea where on the site they are.* All I can really do is tag those amenities as attributes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
It is a bit of a philosophical question: do you prefer a placeholder or a polygon of which you don't know how correct it is, for example a forest behind the campsite that may or may not be part of the campground. On Fri, Mar 27, 2015 at 1:57 PM Marc Gemis wrote: > In many cases you will be able to determine the area from the aerial > images (thinking of Western European campsites). > I assume that in the campsites you visited, the actual area was rather > fuzzy and that the exact area will never been known, not ? OSM has no > solution for fuzzy areas anyhow. > > Is it difficult to obtain an approximation of the area when you already go > through the effort to position all the amenities as individual nodes ? > you can always leave a note or fixme tag to indicate that the shape has to > be established. > > just my .5 cents > > regards > > m > > On Fri, Mar 27, 2015 at 12:37 PM, Jan van Bekkum > wrote: > >> So if you don't know the real shape of the polygon it would be best to >> create a placeholder polygon (like a circle - it will be clear that it is a >> placeholder) and put all amenities inside it until the real shape is known. >> >> On Fri, Mar 27, 2015 at 10:33 AM Marc Gemis wrote: >> >>> Overpass understands this. When I look for all toilets in the "Zoo >>> Antwerpen" with [1], I only find toilets in that Zoo >>> >>> regards >>> >>> m >>> >>> [1] http://overpass-turbo.eu/s/8qL >>> >>> On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis >>> wrote: >>> > OK, I did not know that ! Is this "is-in-polygon" test something that > is already being done ? Examples ? > Nominatim that adds the address of the building to the POI is an example of a similar test / algorithm. Sorry, don't know any other examples. But it just makes sense that you do not have to define inclusion of something when you can determine that from it's position. I also only know 1 website that supports the site relation, the geschichtskarte for historical items regards m >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >> > ___ > 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] Tagging method of amenities at camp_sites
In many cases you will be able to determine the area from the aerial images (thinking of Western European campsites). I assume that in the campsites you visited, the actual area was rather fuzzy and that the exact area will never been known, not ? OSM has no solution for fuzzy areas anyhow. Is it difficult to obtain an approximation of the area when you already go through the effort to position all the amenities as individual nodes ? you can always leave a note or fixme tag to indicate that the shape has to be established. just my .5 cents regards m On Fri, Mar 27, 2015 at 12:37 PM, Jan van Bekkum wrote: > So if you don't know the real shape of the polygon it would be best to > create a placeholder polygon (like a circle - it will be clear that it is a > placeholder) and put all amenities inside it until the real shape is known. > > On Fri, Mar 27, 2015 at 10:33 AM Marc Gemis wrote: > >> Overpass understands this. When I look for all toilets in the "Zoo >> Antwerpen" with [1], I only find toilets in that Zoo >> >> regards >> >> m >> >> [1] http://overpass-turbo.eu/s/8qL >> >> On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis >> wrote: >> >>> OK, I did not know that ! Is this "is-in-polygon" test something that is already being done ? Examples ? >>> >>> Nominatim that adds the address of the building to the POI is an example >>> of a similar test / algorithm. >>> Sorry, don't know any other examples. But it just makes sense that you >>> do not have to define inclusion of something when you can determine that >>> from it's position. >>> >>> I also only know 1 website that supports the site relation, the >>> geschichtskarte for historical items >>> >>> regards >>> >>> m >>> >>> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > ___ > 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] Tagging method of amenities at camp_sites
So if you don't know the real shape of the polygon it would be best to create a placeholder polygon (like a circle - it will be clear that it is a placeholder) and put all amenities inside it until the real shape is known. On Fri, Mar 27, 2015 at 10:33 AM Marc Gemis wrote: > Overpass understands this. When I look for all toilets in the "Zoo > Antwerpen" with [1], I only find toilets in that Zoo > > regards > > m > > [1] http://overpass-turbo.eu/s/8qL > > On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis wrote: > >> >>> OK, I did not know that ! Is this "is-in-polygon" test something that >>> is already being done ? Examples ? >>> >> >> Nominatim that adds the address of the building to the POI is an example >> of a similar test / algorithm. >> Sorry, don't know any other examples. But it just makes sense that you do >> not have to define inclusion of something when you can determine that from >> it's position. >> >> I also only know 1 website that supports the site relation, the >> geschichtskarte for historical items >> >> regards >> >> m >> >> > ___ > 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] Tagging method of amenities at camp_sites
Overpass understands this. When I look for all toilets in the "Zoo Antwerpen" with [1], I only find toilets in that Zoo regards m [1] http://overpass-turbo.eu/s/8qL On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis wrote: > >> OK, I did not know that ! Is this "is-in-polygon" test something that >> is already being done ? Examples ? >> > > Nominatim that adds the address of the building to the POI is an example > of a similar test / algorithm. > Sorry, don't know any other examples. But it just makes sense that you do > not have to define inclusion of something when you can determine that from > it's position. > > I also only know 1 website that supports the site relation, the > geschichtskarte for historical items > > regards > > m > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
> > > OK, I did not know that ! Is this "is-in-polygon" test something that > is already being done ? Examples ? > Nominatim that adds the address of the building to the POI is an example of a similar test / algorithm. Sorry, don't know any other examples. But it just makes sense that you do not have to define inclusion of something when you can determine that from it's position. I also only know 1 website that supports the site relation, the geschichtskarte for historical items regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
On Fri, 2015-03-27 at 09:58 +0100, Marc Gemis wrote: > "It is not necessary or appropriate to use a relation when all the > elements contained within the boundary of the site belong to the site, > and no elements beyond that boundary do belong. In this simple case > simply tag the perimeter with all the appropriate tags. Users of the > information can simply perform an 'is-in-polygon' test to determine > which elements belong to the site." [1] OK, I did not know that ! Is this "is-in-polygon" test something that is already being done ? Examples ? It does mean that a camp_site needs to be mapped as a polygon, not a node but thats not too bad. David > > > > > regards > > > > > m > > > [1] http://wiki.openstreetmap.org/wiki/Relation:site > > > > > > On Fri, Mar 27, 2015 at 9:52 AM, David Bannon > wrote: > On Fri, 2015-03-27 at 07:31 +, Jan van Bekkum wrote: > > > Separate nodes for campground and amenities > connected in a site relation > > Only practical solution IHMO. > > David > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > > > ___ > 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] Tagging method of amenities at camp_sites
Please remember "It is not necessary or appropriate to use a relation when all the elements contained within the boundary of the site belong to the site, and no elements beyond that boundary do belong. In this simple case simply tag the perimeter with all the appropriate tags. Users of the information can simply perform an 'is-in-polygon' test to determine which elements belong to the site." [1] regards m [1] http://wiki.openstreetmap.org/wiki/Relation:site On Fri, Mar 27, 2015 at 9:52 AM, David Bannon wrote: > On Fri, 2015-03-27 at 07:31 +, Jan van Bekkum wrote: > > > Separate nodes for campground and amenities connected in a site > relation > > Only practical solution IHMO. > > David > > > > ___ > 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] Tagging method of amenities at camp_sites
On Fri, 2015-03-27 at 07:31 +, Jan van Bekkum wrote: > Separate nodes for campground and amenities connected in a site > relation Only practical solution IHMO. David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
Apply 3 in case all amenities fall in 1 area. Apply 4 in case they are in separate areas. Use 1 only in a first iteration when no more details are known. don't like 2 at all :-) I think camp sites are no different that large factories, schools, universities etc. in this respect. regards m On Fri, Mar 27, 2015 at 8:31 AM, Jan van Bekkum wrote: > This is a spinoff of a discussion that was started in the mail trail about > the proposal for camp_site=* that is currently open for comments. I would > like to limit this discussion to facilities for the entire campground, not > individual pitches. Similar questions will apply to other situations than > campsites. > > Certain amenities that are offered with campgrounds have their own > namespace key. Examples are restaurant, bar, shop, shower. Others like > toilets and internet can be attributes under tourism=camp_site. > > Let's take as an example a campsite with restaurant and shower. > For tagging a restaurant plus showers that belong to a campground > different approaches can be chosen: > >1. The node or area tourism=camp_site gets one attribute >amenity=restaurant;showers. >Advantage: (1) evident that shower and restaurant belong to >campground, (2) no new tag definitions needed >Disadvantages: (1) additional attributes for individual amenities >(like opening_hours=* not possible, (2) difficult to render >2. New attributes are created such as restaurant=yes, showers=hot, >restaurant:opening_hours=* >Advantage: (1) evident that shower and restaurant belong to >campground, (2) attributes for individual amenities possible >Disadvantages: (1) duplication of tag definitions for the same object >(amenity=shower and shower=hot), (2) difficult to render >3. Separate nodes for campground and amenities >Advantages: (1) no new tag definitions needed, (2) attributes per >amenity straightforward, (3) no rendering issues >Disadvantages: (1) not evident that campground and amenities belong >together, (2) placing of nodes incorrect if layout of camping area is not >known >4. Separate nodes for campground and amenities connected in a site >relation >Advantages: (1) no new tag definitions needed, (2) attributes per >amenity straightforward, (3) no rendering issues, (4) evident that >campground and amenities belong together, (5) acceptable rendering even if >relation isn't properly handled by rendering software >Disadvantages: (1) placing of nodes incorrect if layout of camping >area is not known, (2) use of relations felt to be difficult by some >mappers. > > All in all I personally prefer option 4. > > Opinions? > > Regards, > > Jan van Bekkum > > > > > > ___ > 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] Tagging method of amenities at camp_sites
On 27/03/2015 6:31 PM, Jan van Bekkum wrote: This is a spinoff of a discussion that was started in the mail trail about the proposal for camp_site=* that is currently open for comments. I would like to limit this discussion to facilities for the entire campground, not individual pitches. Similar questions will apply to other situations than campsites. Certain amenities that are offered with campgrounds have their own namespace key. Examples are restaurant, bar, shop, shower. Others like toilets and internet can be attributes under tourism=camp_site. Let's take as an example a campsite with restaurant and shower. For tagging a restaurant plus showers that belong to a campground different approaches can be chosen: 1. The node or area tourism=camp_site gets one attribute amenity=restaurant;showers. Advantage: (1) evident that shower and restaurant belong to campground, (2) no new tag definitions needed Disadvantages: (1) additional attributes for individual amenities (like opening_hours=* not possible, (2) difficult to render 2. New attributes are created such as restaurant=yes, showers=hot, restaurant:opening_hours=* Advantage: (1) evident that shower and restaurant belong to campground, (2) attributes for individual amenities possible Disadvantages: (1) duplication of tag definitions for the same object (amenity=shower and shower=hot), (2) difficult to render 3. Separate nodes for campground and amenities Advantages: (1) no new tag definitions needed, (2) attributes per amenity straightforward, (3) no rendering issues Disadvantages: (1) not evident that campground and amenities belong together, (2) placing of nodes incorrect if layout of camping area is not known 4. Separate nodes for campground and amenities connected in a site relation Advantages: (1) no new tag definitions needed, (2) attributes per amenity straightforward, (3) no rendering issues, (4) evident that campground and amenities belong together, (5) acceptable rendering even if relation isn't properly handled by rendering software Disadvantages: (1) placing of nodes incorrect if layout of camping area is not known, (2) use of relations felt to be difficult by some mappers. All in all I personally prefer option 4. For me .. Number 4. The incorrect layout of nodes within the area; conveys the information that they exist and are not too much trouble to correct when that data becomes available. In fact it makes it easier for the correction - just move the node. Option 4 is easy, simple, effective and adds no new stuff to OSM. 'Just' needs documentation for camp_sites? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging method of amenities at camp_sites
I like the values you proposed (the camp_site=opportunistic_hospitality email) and option #4 here - if the relation values are straight forward, then people will make the jump to learn it. I also suggest a fallback note on the proposal,, such "as map the area, amenities, and information as best as possible, and create a new “map note” on the main OSM view to ask for another mapper to complete the relation/mapping.” This way the only thing left to do for a more experienced (but less familiar with the site) mapper is to make the relation. I look around my area every month to see if there are any new anonymous repair tags people have added to the map, so it could get fixed that way. are fixme= notes also acceptable? Javbw > On Mar 27, 2015, at 4:31 PM, Jan van Bekkum wrote: > > This is a spinoff of a discussion that was started in the mail trail about > the proposal for camp_site=* that is currently open for comments. I would > like to limit this discussion to facilities for the entire campground, not > individual pitches. Similar questions will apply to other situations than > campsites. > > Certain amenities that are offered with campgrounds have their own namespace > key. Examples are restaurant, bar, shop, shower. Others like toilets and > internet can be attributes under tourism=camp_site. > > Let's take as an example a campsite with restaurant and shower. > For tagging a restaurant plus showers that belong to a campground different > approaches can be chosen: > The node or area tourism=camp_site gets one attribute > amenity=restaurant;showers. > Advantage: (1) evident that shower and restaurant belong to campground, (2) > no new tag definitions needed > Disadvantages: (1) additional attributes for individual amenities (like > opening_hours=* not possible, (2) difficult to render > New attributes are created such as restaurant=yes, showers=hot, > restaurant:opening_hours=* > Advantage: (1) evident that shower and restaurant belong to campground, (2) > attributes for individual amenities possible > Disadvantages: (1) duplication of tag definitions for the same object > (amenity=shower and shower=hot), (2) difficult to render > Separate nodes for campground and amenities > Advantages: (1) no new tag definitions needed, (2) attributes per amenity > straightforward, (3) no rendering issues > Disadvantages: (1) not evident that campground and amenities belong together, > (2) placing of nodes incorrect if layout of camping area is not known > Separate nodes for campground and amenities connected in a site relation > Advantages: (1) no new tag definitions needed, (2) attributes per amenity > straightforward, (3) no rendering issues, (4) evident that campground and > amenities belong together, (5) acceptable rendering even if relation isn't > properly handled by rendering software > Disadvantages: (1) placing of nodes incorrect if layout of camping area is > not known, (2) use of relations felt to be difficult by some mappers. > All in all I personally prefer option 4. > > Opinions? > > Regards, > > Jan van Bekkum > > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
