[Tagging] vending= How to handle food & drinks
Usually it is pretty obvious when you should make a new value and when not, but with food and drinks it is endless: http://taginfo.openstreetmap.org/keys/vending#values If you use vending=milk instead of vending=drinks+drink:milk=yes where do you draw the line? Does vending=drinks assume soft drinks? Or does that get its own tag? What happens when OSM gets more popular in other parts of the word where different products are popular? What about bbq meat (had that discussion on the DE mailing list). Also what about sweets? According to the wiki should have been used for the small ones for children, not the big ones at the train station where you can get a Mars or Snickers. (Those Gumball vending machines are actually the other big issue on their own) After long consideration I think the best solution is to use drinks & food for everything as umbrella term and then require the use of drink:/food: tags to be more specific. The main advantages I see: 1. vending= drinks, food and drinks;food would cover most cases (if including "sweets") 2. No different definitions/interpretations about what drinks/food on their own stand for 3. drink: / food: is universally and can be combined with other tags (bars, restaurants...) - less documentation 4. One system and not some arbitrary line where it changes (e.g. from vending=abc to vending=drinks+drink:abc=yes) 5. Allows for more specific tagging that is easier to consume (vending=drinks+drink:soft_drink=yes+drink:water=yes+drink:coca-cola=yes instead of vending=drinks/soft_drinks;water+... or something like that) 6. No redundant tagging possible (like vending=water+drink:water=yes) What do you think? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] vending= How to handle food & drinks
I think that when we get to that level, we can have no more structure in tagging. The last structured tag should be "vending=food;drinks", and after that all the other values should be crumpled into one tag. Something like: food=sandwitches;Mars;Snickers;bubblegum;chocolate;salty snacks;ice cream;... and treat it simmilar to note=* tag. If anyone is going to use that data, it's not going to be anything more than showing all the text raw to the user. Janko 2014-07-11 17:01 GMT+02:00 Andreas Goss : > Usually it is pretty obvious when you should make a new value and when > not, but with food and drinks it is endless: > http://taginfo.openstreetmap.org/keys/vending#values > > If you use vending=milk instead of vending=drinks+drink:milk=yes where do > you draw the line? Does vending=drinks assume soft drinks? Or does that get > its own tag? What happens when OSM gets more popular in other parts of the > word where different products are popular? What about bbq meat (had that > discussion on the DE mailing list). Also what about sweets? According to > the wiki should have been used for the small ones for children, not the big > ones at the train station where you can get a Mars or Snickers. (Those > Gumball vending machines are actually the other big issue on their own) > > After long consideration I think the best solution is to use drinks & food > for everything as umbrella term and then require the use of drink:/food: > tags to be more specific. > > The main advantages I see: > 1. vending= drinks, food and drinks;food would cover most cases (if > including "sweets") > 2. No different definitions/interpretations about what drinks/food on > their own stand for > 3. drink: / food: is universally and can be combined with other tags > (bars, restaurants...) - less documentation > 4. One system and not some arbitrary line where it changes (e.g. from > vending=abc to vending=drinks+drink:abc=yes) > 5. Allows for more specific tagging that is easier to consume > (vending=drinks+drink:soft_drink=yes+drink:water=yes+drink:coca-cola=yes > instead of vending=drinks/soft_drinks;water+... or something like that) > 6. No redundant tagging possible (like vending=water+drink:water=yes) > > What do you think? > > http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine > __ > openstreetmap.org/user/AndiG88 > wiki.openstreetmap.org/wiki/User:AndiG88 > > > ___ > 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] vending= How to handle food & drinks
Hi Janko, I disagree. If (!) any software uses that particular tag, it should/would try to translate at least some of these tags to it's UI language, getting: "Sandwiches, Mars, Snickers, Kaugummi, Schokolade, Salzige Snacks, Eis" as a german example for the tag you mentioned. For showing it as it is (especially without spaces after the semicolons) I don't see any use case where that is the best solution. It might be a first draft or a better-than-nothing approach, but for good software I would expect to be able to see values like this in my language, with correct layout and probably filter by it (e.g. searching for ice cream is very different from searching for salty stuff). The argument that there is no application (yet) that uses the value at all would be valid, then don't tag it (yourself), but don't restrict others just because you don't see the use case. regards Peter Am 11.07.2014 18:35, schrieb Janko Mihelić: > I think that when we get to that level, we can have no more structure in > tagging. The last structured tag should be "vending=food;drinks", and after > that all the other values should be crumpled into one tag. Something like: > > food=sandwitches;Mars;Snickers;bubblegum;chocolate;salty snacks;ice > cream;... > > and treat it simmilar to note=* tag. If anyone is going to use that data, > it's not going to be anything more than showing all the text raw to the > user. > > Janko > > > 2014-07-11 17:01 GMT+02:00 Andreas Goss : > >> Usually it is pretty obvious when you should make a new value and when >> not, but with food and drinks it is endless: >> http://taginfo.openstreetmap.org/keys/vending#values >> >> If you use vending=milk instead of vending=drinks+drink:milk=yes where do >> you draw the line? Does vending=drinks assume soft drinks? Or does that get >> its own tag? What happens when OSM gets more popular in other parts of the >> word where different products are popular? What about bbq meat (had that >> discussion on the DE mailing list). Also what about sweets? According to >> the wiki should have been used for the small ones for children, not the big >> ones at the train station where you can get a Mars or Snickers. (Those >> Gumball vending machines are actually the other big issue on their own) >> >> After long consideration I think the best solution is to use drinks & food >> for everything as umbrella term and then require the use of drink:/food: >> tags to be more specific. >> >> The main advantages I see: >> 1. vending= drinks, food and drinks;food would cover most cases (if >> including "sweets") >> 2. No different definitions/interpretations about what drinks/food on >> their own stand for >> 3. drink: / food: is universally and can be combined with other tags >> (bars, restaurants...) - less documentation >> 4. One system and not some arbitrary line where it changes (e.g. from >> vending=abc to vending=drinks+drink:abc=yes) >> 5. Allows for more specific tagging that is easier to consume >> (vending=drinks+drink:soft_drink=yes+drink:water=yes+drink:coca-cola=yes >> instead of vending=drinks/soft_drinks;water+... or something like that) >> 6. No redundant tagging possible (like vending=water+drink:water=yes) >> >> What do you think? >> >> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine >> __ >> openstreetmap.org/user/AndiG88 >> wiki.openstreetmap.org/wiki/User:AndiG88 >> >> >> ___ >> 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] vending= How to handle food & drinks
and treat it simmilar to note=* tag. If anyone is going to use that data, it's not going to be anything more than showing all the text raw to the user. I completely disagree here. * If I have some kind of public transport app then most of the time I would be interested in some snacks or soft drink / coffee, not so much in vegetables or milk. * If I run a website about BBQ and show a map with grill locations etc. I might only want to add vending machines that sell bqq meat. * If I run some nighlife app I would probably want to display where you can get alcohol. * If I have some kind of farmers market map I probably want to show eggs, milk, potatos etc. not snacks, chocolate or ice cream. Not to mention that I think tagging with semi colons is much more likely to results in errors. And even today without apps I could use overpass and look for amenity=vending_machine+food:bbq=yes so it is already usefull for people more familiar with OSM. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] vending= How to handle food & drinks
On 11 July 2014 18:30, Andreas Goss wrote: > I completely disagree here. > > * If I have some kind of public transport app then most of the time I would > be interested in some snacks or soft drink / coffee, not so much in > vegetables or milk. I prefer to drink milk than other soft drinks, when travelling. > * If I have some kind of farmers market map I probably want to show eggs, > milk, potatos etc. not snacks, chocolate or ice cream. My local farmers' market sells ice cream and chocolate, but not milk. My point is not to argue for one set of tags over anther; but to illustarte that such pinnickety bikeshedding [1], based on one's personal experiences and preferences, is unhelpful and inefficient. [1] https://en.wikipedia.org/wiki/Bikeshedding -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] vending= How to handle food & drinks
+1 My point is not to argue for one set of tags over anther; but to illustarte that such pinnickety bikeshedding [1], based on one's personal experiences and preferences, is unhelpful and inefficient. LOL I totally agree with Andy — Some of these discussions are seemingly endless maybe because, as the Wikipedia article says, everyone knows about snack shops and wants to contribute something. How the heck is any map going to cover ALL the practically infinite variations we might invent to describe shops and other items? It's crazy! Dave On Fri, Jul 11, 2014 at 9:44 AM, Andy Mabbett wrote: > On 11 July 2014 18:30, Andreas Goss wrote: > > > I completely disagree here. > > > > * If I have some kind of public transport app then most of the time I > would > > be interested in some snacks or soft drink / coffee, not so much in > > vegetables or milk. > > I prefer to drink milk than other soft drinks, when travelling. > > > * If I have some kind of farmers market map I probably want to show eggs, > > milk, potatos etc. not snacks, chocolate or ice cream. > > My local farmers' market sells ice cream and chocolate, but not milk. > > My point is not to argue for one set of tags over anther; but to > illustarte that such pinnickety bikeshedding [1], based on one's > personal experiences and preferences, is unhelpful and inefficient. > > > [1] https://en.wikipedia.org/wiki/Bikeshedding > > -- > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > > ___ > 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] vending= How to handle food & drinks
How the heck is any map going to cover ALL the practically infinite variations we might invent to describe shops and other items? It's crazy! The whole point of tagging in more detail is for maps to be able to be more selective about what kind of food/drink vending machines they show. As pointed out different people have different interests and a more detailed tagging schema allows developers to cater to different users and applications. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] Beach routing
On Wed, Jul 9, 2014 at 12:50 PM, Elliott Plack wrote: > OSM US: > > I've been using some routing engines to map fitness routes (e.g. Strava) > that use OSM data. Along our US coasts, there are beaches. The beaches I'm > familiar with are popular with walkers and joggers to go up and down the > shore, since access is generally open to anyone along the water's edge. I'm > considering adding a `highway=path` along the beach to facilitate this. I'd > add the connections to the walking paths between parking lots and the beach > as well. > > For uninterrupted strips of sandy beach, would a path be appropriate to > indicate walkability? Adding a single arbitrary path where an area exists seems a bit of a hack. I recognize that part of the problem that you are trying to address is that routers aren't routing across areas. And that is surely a difficult problem to solve. Is the creation of arbitrary fake-paths a worse problem than not being able to route with specific routing software? Perhaps. A similar situation exists in (micro-)mapping golf courses. Some courses have cart paths with discontinuities. Often those discontinuities direct you to drive the cart (or walk, I'm not "judging" here) on the fairway, until the next section of physical cart path begins. In that situation, I only map the real path, not the virtual path. The another similarity is that users will select different paths for different reasons. Beach walkers may divert towards interesting items on the beach, or away from waves, washouts or debris. Golf players will be guided by course rules, weather rules and the location of their ball. The golf player is probably more likely to complete a predictable circuit. Beach walkers might follow an "out and back" of entirely arbitrary length. Using a router to select a, let's say, 5km stroll, out and back on a beach, seems of limited utility. I suggest, "no path on the beach". Map a boardwalk where one exists, by all means. And adding those access ramps / paths is awesome. ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] convert imported natural=rock areas to bare_rock
My proposal http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup has been in RFC state for a year, and the only comment from other users was a personal message concerning the licence of my photos. So it seems that there are no objections, and that we should proceed to voting. However, I feel uncomfortable about the cleanup chapter, because it's about nebulous subsequent edits on an unknown amount of data. Therefore I would like to make some cleanups beforehand, and then see what is left. I would like to start with data from the French Corine Land Cover import, because *all* the natural=rock generated by that import actually mean natural=bare_rock. Renaming these tags cannot do any harm, because an ambiguous tag is replaced which an anambiguous and approved tag which perfectly matches the intended meaning. In detail, it's about: - replacing natural=rock with natural=bare_rock - for all areas (ways, MPs) with source="Union européenne - SOeS, CORINE Land Cover, 2006." The data can be retrieved with: http://overpass-api.de/api/xapi?*[natural=rock][source=Union europ\xc3\xa9enne - SOeS, CORINE Land Cover, 2006.] There are 1216 objects to change. Is this subject to the mechanical edit policy? If so, where should it be discussed? What user account shall be used? Are there any reasons not to do it at all? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] convert imported natural=rock areas to bare_rock
> Am 12/lug/2014 um 00:27 schrieb Friedrich Volkmann : > > My proposal > http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup > has been in RFC state for a year Maybe a whole year is a bit long... 3 comments: - you write natural=bare_rock is about rock as the surface material, so I think this would better fit in the keys "surface" or "landcover" - the distinction between stone and rock as the latter being firmly attached to the bedrock might often be difficult to verify on the ground -I don't like that "rock" can mean one rock or a group of rocks with at least one of them attached. If we are to bring in more detail, why not distinguish between one rock and a group of rocks? And shouldn't from the group of rocks those that are not firmly attached to the ground be tagged "stone" according to your proposal and hence left out if the rock-tag? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] convert imported natural=rock areas to bare_rock
On 12.07.2014 01:01, Martin Koppenhoefer wrote:
>> Am 12/lug/2014 um 00:27 schrieb Friedrich Volkmann :
>>
>> My proposal
>> http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup
>> has been in RFC state for a year
>
>
> Maybe a whole year is a bit long...
>
> 3 comments:
> - you write natural=bare_rock is about rock as the surface material, so I
> think this would better fit in the keys "surface" or "landcover"
That's how natural=bare_rock is defined ("areas made principally or mostly
of solid rock"), analogous to natural=water/sand/grass/glacier/etc. all of
which are about the surface. The bare_rock proposal was approved 2 years ago
and there are 64 566 occurrences by now.
> - the distinction between stone and rock as the latter being firmly attached
> to the bedrock might often be difficult to verify on the ground
When in doubt, tag what seems most certain. That's natural=rock in most
cases. Estimations and guesses are daily business in mapping. Like guessing
tracktypes and landuses when mapping from arial images.
> -I don't like that "rock" can mean one rock or a group of rocks with at least
> one of them attached.
> If we are to bring in more detail, why not distinguish between one rock and a
> group of rocks?
See the last picture in my proposal. Is it one rock or two? You cannot tell,
because there are firmly attached to each other. If you map 2 rocks, how do
you tag the name? The name "Franzosenstein" belongs to the whole rock
formation alltogether. There's also a formation of 7 rocks called "7
Kurfürsten". It would be highly impractical to map them separately. This
kind of micro mapping should be possible, but not obligatory.
> And shouldn't from the group of rocks those that are not firmly attached to
> the ground be tagged "stone" according to your proposal and hence left out if
> the rock-tag?
You surely know the German term "Wackelsteine". A wackelstein consists of
one bottom rock connected to the ground, and one or more (more =>
Doppelwackelstein) rocks on top. They are commonly considered one single
rock formation, and therefore it should be one single object in OSM as well.
I use to map them as natural=rock, not stone, because the formation as a
whole is connected to the ground.
According to its wiki page, natural=stone is "a single notable freestanding
rock". This obviously does not apply to wackelsteins, because they are
neither single nor freestanding.
natural=stone is mainly intended for erratics, which are almost never
accompanied by rocks connected to the ground.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] convert imported natural=rock areas to bare_rock
On Sat, 12 Jul 2014 00:27:03 +0200, Friedrich Volkmann wrote: > My proposal > http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup > has been in RFC state for a year, and the only comment from other > users was a personal message concerning the licence of my photos. When a proposal just sits in a wiki and doesn't get spread actively by it's author on OSM channels (forums, mailing lists) it doesn't get much attention. Even /when/ it is spread a lot of people (I included) often prefer to let it be. > So it seems that there are no objections, and that we should > proceed to voting. However, I feel uncomfortable about the cleanup > chapter, because it's about nebulous subsequent edits on an unknown > amount of data. Therefore I would like to make some cleanups > beforehand, and then see what is left. > [copied some cited stuff from the end of the msg here] > There are 1216 objects to change. > > Is this subject to the mechanical edit policy? If so, where should it > be discussed? What user account shall be used? Are there any reasons > not to do it at all? The whole proposal is imho one of a mechanical edit. How to do one is documented here: http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy > I would like to start with data from the French Corine Land Cover > import, because *all* the natural=rock generated by that import > actually mean natural=bare_rock. For changing a french import you should discuss this with the french community. OT remark: As all Corine data I saw so far it is quite imprecise. Of course the ways cover mostly the landuse they are described to cover, but (e.g. as for woods) they often cover meadows and farmlands, too. This kind if imports are good to get a country full of landuse but not precise data. And enhancing MPs with 150 km outer ways is not what all mappers do enjoy much. > Renaming these tags cannot do any harm, because an ambiguous tag is > replaced which an anambiguous and approved tag which perfectly > matches the intended meaning. For the proposal itself I don't have much objections. IIRC I mapped some natural=rock on nodes which should have been natural=stone but due to my German roots a stone is something I can pick up from the ground – unlike a rock. :) hth Thomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
