Re: [Tagging] Please don't think name_1 tags are errors.
W dniu 20.01.2016 23:17, moltonel 3x Combo napisał(a): Concerning your suggestion to use "name=n1 alt_name=n2;n3", let me rethorically wonder why you didn't suggest "name=n1;n2;n3" ? I expect it is because the risk of semicolons in the "name" tag catching some consumers unaware. Well, that risk of catching consumers unaware is pretty much the same with semicolons in "name" as in "alt_name". I'm sorry if I don't fit in the context, because I don't follow this thread, but I know at least one valid case, where we need to know proper sequence of elements and semicolon notation would be not suitable - think of long inscriptions on monuments/memorials (and we have only 255 chars available per value, IIRC). It's a technical problem with our tagging system - no nesting, no sequencing and only one value per key are the most visible ones for me. -- "Завтра, завтра всё кончится!" [Ф. Достоевский] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On 17/01/2016, Hakuch wrote: > for me the use of alt_name_1 is more logical than the name_1, because > alt_name is the meaning of name_1! So, if you have a second name and you > dont know where to put it (loc_name, old_name...) you can use alt_name. > And if you have a third name you SHOULD use alt_name:name2;name3 but in > a bad manor you can use alt_name_1=name2, alt_name_2=name3. But name_1 > doesn't make any sense. Well "alt_foo" and "foo_1" both mean "here's another value for foo". So "alt_foo_1" expand to something like "here's another another value for foo". "alt_" and "_1" are two ways of saying "another", and juxtaposing two "adverbs" with the same meaning is superfluous and grammatically akward. To use another analogy, it's like talking about the "TCP protocol" or the "MIT institude of technology". And because "_1" naturally naturally brings "_2" and so on (while "alt_" doesn't naturally bring any followup), it makes sense to give up on "alt_" altogether. It doesn't bring any benefit compared to "_1" (but "loc_", "old_" and others are still ok because they carry a different meaning). Concerning your suggestion to use "name=n1 alt_name=n2;n3", let me rethorically wonder why you didn't suggest "name=n1;n2;n3" ? I expect it is because the risk of semicolons in the "name" tag catching some consumers unaware. Well, that risk of catching consumers unaware is pretty much the same with semicolons in "name" as in "alt_name". So when are semicolons a reasonable way to specify multiple values ? IMHO whenever the values are fixed or sanitizable (unlike for example "name", which the mapper has no control over), and empty fields don't make sense. There are actually quite few of them that wouldn't benefit from a more elaborate mapping or tagging scheme. "Sport" and "ref" are likely fine, but I'd rather leave the fun of determining which keys are semicolon-safe as an exercise to future generations of mappers and consumers. Myself, I'd rather use foo_1 everywhere and stop worrying. Obligatory xkcd quote: https://xkcd.com/327/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On 20/01/2016 05:30, Bryce Nesbitt wrote: On Fri, Jan 15, 2016 at 8:25 AM, Ralph Aytoun mailto:ralph.ayt...@ntlworld.com>> wrote: New mappers have a lot to learn. They have enough of a problem just learning how to use the tools and finding out what basic tagging is without being inundated with error messages telling them they cannot save their work because of some technical fault. Let them save their work rather than it getting lost or they get so frustrated that they give up and walk away. An error condition is a perfect "teaching moment" where iD could explain tagging convention (rather than hiding it). +1 Amending existing tags is a major part of OSM editing & not something that should be swept under the carpet. Dave F. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On Fri, Jan 15, 2016 at 8:25 AM, Ralph Aytoun wrote: > > New mappers have a lot to learn. They have enough of a problem just > learning how to use the tools and finding out what basic tagging is without > being inundated with error messages telling them they cannot save their > work because of some technical fault. Let them save their work rather than > it getting lost or they get so frustrated that they give up and walk away. An error condition is a perfect "teaching moment" where iD could explain tagging convention (rather than hiding it). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
Hi On 15.01.2016 23:01, Dave F. wrote: > On 15/01/2016 16:25, Ralph Aytoun wrote: >> I object to the continuous use of naming new mappers as a problem. > > Are you sure it's not the design of the editor that's being called out > as the culprit? I join this view, Iam not considering the people who learn mapping to be the problem, but this feature in iD. On 15/01/2016 16:25, Ralph Aytoun wrote: > New mappers have a lot to learn. They have enough of a problem just > learning how to use the tools and finding out what basic tagging is > without being inundated with error messages telling them they cannot > save their work because of some technical fault. Let them save their > work rather than it getting lost or they get so frustrated that they > give up and walk away. I know you mean it well, but I think you don't do well when you want to protect people from learning *very basic principles* of tagging: "Where there is one keyname, there cant be the same again." And I do really trust in every "newbie" that this principle is very easy and very fast learnable. On 15/01/2016 16:25, Ralph Aytoun wrote: > And believe me when I say that they are nor learning bad tagging from > the iD Editor because most new mappers will not understand what just > happened or that the tag is different, they will just be grateful that > their work has been saved and they can continue mapping. I understand, that you want to keep new people in mapping, but I think it is a bad way to simulate a easy-peasy tagging world. As I mentioned above, I am sure that people will easily learn that there should be one only one keyname. I guess that is even easier to learn than letting them put values that are not consistent. They will be even more frustrated when they tagged a lot of stuff and wont find it on the map or in nominatim. Again, I think leading new people to produce garbage is a very bad way of motivation. And being happy that people are grateful and continue wrong mapping is even no way of satisfication. I find, it is very ok to tell people if something is wrong, even more if it not possible to save data in the way they want to. But I agree to find a good way to tell them, not like "something ist wrong with your tags, please correct" when you click on the save button, thats bullshit. It should be immediatly when you want to create the same-named tag, and it should be hyperlinked to a more detailed description of the principle. It could even be something like "oh you want to create another name, is the original one wrong? do you want to add one? maybe one of this fits? if you are not sure, you can use fixme:XXX or you can use alt_name=XXX" However, I really dont like the behavior of iD (.developers) to use their position as beeing the gate between mappers and the database to produce new tags that has not been accepted in official proposals by the community. Its like one of the JOSM developers said, when he changed to the OSM board: He had more influence when he was developing the editor. 0x3CBE432B.asc Description: application/pgp-keys ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
Hi On 15.01.2016 18:03, moltonel 3x Combo wrote: > Changing the topic a little bit, I'd like to comment on alt_name vs > name_1 va alt_name_1. To me name_1 and alt_name are exact synonyms, I > don't see a semantic difference (as opposed to loc_name for example). > Therefore, if you've only got two names to tag you can use either. But > once you've got at least three you'll need to use either alt_name_N or > name_N. I find the concept of alt_name_N silly and would rather use > name_N, but I've seen some people disagree, For what it's worth, > alt_name_N is much less frequent in the db than name_N, but Nominatim > supports only alt_name_N. Any opinions on that issue (other than > "remove all *_N" :p) ? as I mentioned in my proposal about removing the alt_name_1 and name_1 from wiki: the alt_name_1 in nominatim was rolled out by a single data importer who asked a Nominatim developer directly to implement it. So there wasn't any process within the community structures. for me the use of alt_name_1 is more logical than the name_1, because alt_name is the meaning of name_1! So, if you have a second name and you dont know where to put it (loc_name, old_name...) you can use alt_name. And if you have a third name you SHOULD use alt_name:name2;name3 but in a bad manor you can use alt_name_1=name2, alt_name_2=name3. But name_1 doesn't make any sense. 0x3CBE432B.asc Description: application/pgp-keys ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
sent from a phone > Am 15.01.2016 um 22:48 schrieb moltonel 3x Combo : > > I don't recall encountering a multiple-name object that ought to > be broken down in two objects. No stats, just your subjectivity > against mine :p this part of my mail was more generally referring to multivalues in formal keys, not to names where I agree that breaking them down is not an option usually. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On 15/01/2016 16:25, Ralph Aytoun wrote: I am quite in favour of people coming forward to discuss the possibility of improving the iD Editor if it is causing problems. Could a "this key already exists,,," dialog be displayed? I object to the continuous use of naming new mappers as a problem. Are you sure it's not the design of the editor that's being called out as the culprit? Dave F. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On 15/01/2016, Martin Koppenhoefer wrote: >> Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo : >> To get back to my http://www.openstreetmap.org/relation/5257865 >> example, I've got 3 names to tag. One of them distinguishes itself by >> also appearing on an out-of-copyright map, the other two are at the >> exact same level with each other and, as far as I'm concerned, pretty >> much at the same level as the first one. I can't fit them into "loc" >> or "old" or "whatever" categories, to the best of my knowledge they >> are just "other names". > > if one of your sources "authorative", you could put the value under > official_name, the other two could be name and alt_name (if there really > isn't just a typo at least in one of them). That'd actually be worse in this case, because the "authoritative" spelling is also probably the most frequent one, that should go in the "name" tag. The "official_name" tag is only interesting when the official name differs from the common name. See what happened ? Even though you agreed above that one shouldn't "shuffle all your names into random foo_name keys", that's pretty much what you suggested here. Not exactly "random" keys, but still trying to shoehorn the three names into correct-looking foo_name tags, when the reallity calls for putting all three names are at the same level. >> Having multiple values for one tag is awkward in OSM, so we always try >> to find clever ways around it. Sometimes that clever trick is the >> right thing to do, sometimes we really just need a way to tag multiple >> values. > > +1, I agree there might really be situations where this could be the best > solution, but it is really, really rare, most of the cases where multiple > values are actually used come from approximative mapping and would better be > solved by more detail (e.g. area in area or node(s) in area rather than > trying to put everything in one poor node). Assuming all objects with a "(alt_)name_1" tag also have a "name" tag, it amounts to 1.6% of the named objects (BTW, that's more than for the "alt_name" tag). I'm sure some of those can be attributed to bad mapping, but I wouldn't dare state that it is the case for most of them. I don't recall encountering a multiple-name object that ought to be broken down in two objects. No stats, just your subjectivity against mine :p Go ahead and add details where need be. But don't treat name_N as a tag that should be avoided whenever possible, or that is intrinsically inferior to foo_name. It's just another option, to be used whenever it makes sense. It is well established, and consumers whishing to take alternate names into account should include those. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On Friday 15 January 2016, Ralph Aytoun wrote: > When I started a waterway=wadi was an accepted tag > but within a period of three months it was deprecated by a group that > did not really understand it's cartographic usage. I don't want to hijack this thread but the above is not quite correct - on the wiki the tag was indicated as having issues with verifiability and discussion was opened regarding this more than a year earlier: http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dwadi&oldid=953081 But you indeed correctly identified the problem that mappers had a highly variable understanding of what this tag means and its use was very incoonsistent as a result. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
sent from a phone > Am 15.01.2016 um 17:25 schrieb Ralph Aytoun : > > Throughout the arid countries we now have these features > (wadi/ouadi/arroyo/dry gulch/ etc.) without an appropriate tag. time to make a proposal ;-) cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
sent from a phone > Am 15.01.2016 um 17:40 schrieb Marc Gemis : > > I'll agree with what you wrote, but I still wonder how you > differentiate between all the supermarket types. I don't yet, but it is indeed a field where we might want to map more detail in the future. > > I'm thinking about > > * in some countries supermarkets do not sell alcoholic beverages yes, in others they do or not sell cigarettes, or ammunition. > * some supermarkets sells newsletters, card, cleaning products > * some chains are famous for selling 1 type of computer, smartphone, > or clothes for 1 week. special offers don't belong into osm, IMHO > * the larger ones sometimes sells toys, bicycles, TVs, etc. > > I was planning on writing a diary entry about supermarkets, but didn't > found the time yet. > (e.g. on how do you map that certain areas are manned - wine, butcher, > cheese, backery) yes, also fish, fresh sweets, deli, ... These could become attributes... Maybe we should also have an attribute to say something like style=discounter Or a scheme for ware groups, e.g. newspapers, electronics, gardening stuff, stationery, pharmaceutical products... A lot of the details are country specific, partly due to the legal situation but more due to cultural differences. This is a big problem because most mappers will not even be aware of it and although it would be useful for ignorant tourists they will hardly be willing to add a lot of tags for details they take for granted ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
sent from a phone > Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo : > > The problem is that all those name key variations carry semantic > meaning. A loc_name isn't the same thing as an alt_name which isn't > the same thing as an old_name. yes, but a name, an alt_name and a nat_name are quite the same. I haven't yet encountered situations with more then 3 alternative names in the same language for the same thing, and that didn't fit into other kinds of distinctions either (short, official, old, ...). Are we maybe talking about different spelling (e.g. often coming from different transcription of non-latin scripts)? > You can't shuffle all your names into > random foo_name keys, it has to make sense. +1 > And as soon as you've got > more than one name, you've got a problem. IMHO more than 2-3 (alt_name and nat_name). I've looked a bit around in taginfo and found an example for excessive indexed alt names: http://www.openstreetmap.org/relation/5725722 to me this looks as if the mappers wanted to work around some supposedly bad working search engine, looks more like SEO then like sensible tagging, but I might be wrong, I don't know the context. > > To get back to my http://www.openstreetmap.org/relation/5257865 > example, I've got 3 names to tag. One of them distinguishes itself by > also appearing on an out-of-copyright map, the other two are at the > exact same level with each other and, as far as I'm concerned, pretty > much at the same level as the first one. I can't fit them into "loc" > or "old" or "whatever" categories, to the best of my knowledge they > are just "other names". if one of your sources "authorative", you could put the value under official_name, the other two could be name and alt_name (if there really isn't just a typo at least in one of them). > Having multiple values for one tag is awkward in OSM, so we always try > to find clever ways around it. Sometimes that clever trick is the > right thing to do, sometimes we really just need a way to tag multiple > values. +1, I agree there might really be situations where this could be the best solution, but it is really, really rare, most of the cases where multiple values are actually used come from approximative mapping and would better be solved by more detail (e.g. area in area or node(s) in area rather than trying to put everything in one poor node). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On 15/01/2016, Kieron Thwaites wrote: > I completely endorse the removal of any and all *_N tags. If so, you've got a serious amount of work comming up just to figure how to say the same thing using different tags. Semicolons and various namespaced schemes sometimes do the trick, but outright banning *_N for the sake of (what ?) would cause a lot of headaches. On 15/01/2016, Martin Koppenhoefer wrote: > 2016-01-15 15:26 GMT+01:00 moltonel 3x Combo : > also shop_1 tags are created that way. I wonder why you would want to add > these tags on purpose. E.g. for shops the values indicate a type of shop. A > bookstore that also sells music cds? Still a bookstore IMHO. A music store > that also sells some books? Still a music store. Now, a store that sells > both, music cds and books, and maybe dvds and posters, maybe still a > bookstore, maybe a new category like a media store, not sure, would have to > decide on the particular case. In a majority of cases you still can decide > on one of the types and that it is. A green grocer that also sells > toothpaste, detergents, toys and cheese? That likely not a green grocer any > more, that's either a convenience store or a supermarket. > What I want to say: a shop that is 2 shops in one might well be neither of > these shop types, but a new typology. > In other cases, there is a well defined shop/restaurant/bar/kiosk/... which > also offers some odd service or product you might find in some but not all > of this kind of business, and which you consider so interesting that you > want to map the presence of it. Examples might be tobacco/cigarettes, > icecream, particular soft drinks (club_mate comes to mind [1]), public > transport tickets, fresh milk, etc. Yes, "shop=foo shop_1=bar" is not great. In the same way that "shop=foo;bar" is not great. I'm all for either finding a new fitting value or for tagging the main value plus a subtag, or for using two objects. But often mappers are not knowledgable enough or do not have the time to fuss about this, and instead "simply want to express that this is a deli and an optician". > My solution for this is sells:foo=yes(/no/etc.) > Obviously we wouldn't want people to tag the whole assortment of a > supermarket like this, but due to the amount of work the risk is low. > People will likely just tag the things they are particularly interested in, > and that are not automatically thought of being available generally. So far > the list is small ;-) [2] Yes, ns:foo=boolean is a good alternate scheme, when you can use it. > For names, the solution should be to use well defined name key variations, > there's a whole lot of them [3], and introducing just another infinite > amount of indexed ones seems completely unnecessary. The problem is that all those name key variations carry semantic meaning. A loc_name isn't the same thing as an alt_name which isn't the same thing as an old_name. You can't shuffle all your names into random foo_name keys, it has to make sense. And as soon as you've got more than one name, you've got a problem. Which is solved very nicely by _N. To get back to my http://www.openstreetmap.org/relation/5257865 example, I've got 3 names to tag. One of them distinguishes itself by also appearing on an out-of-copyright map, the other two are at the exact same level with each other and, as far as I'm concerned, pretty much at the same level as the first one. I can't fit them into "loc" or "old" or "whatever" categories, to the best of my knowledge they are just "other names". Which is solved very nicely by putting them in name_1 and name_2. Having multiple values for one tag is awkward in OSM, so we always try to find clever ways around it. Sometimes that clever trick is the right thing to do, sometimes we really just need a way to tag multiple values. Semicolons and _N are two ways to do that, each with their pros and cons (I don't think it likely or desirable to deprecate one for the other). They are sometimes usefull, please leave them be an accept them as another tool in your mapper's toolbox. Changing the topic a little bit, I'd like to comment on alt_name vs name_1 va alt_name_1. To me name_1 and alt_name are exact synonyms, I don't see a semantic difference (as opposed to loc_name for example). Therefore, if you've only got two names to tag you can use either. But once you've got at least three you'll need to use either alt_name_N or name_N. I find the concept of alt_name_N silly and would rather use name_N, but I've seen some people disagree, For what it's worth, alt_name_N is much less frequent in the db than name_N, but Nominatim supports only alt_name_N. Any opinions on that issue (other than "remove all *_N" :p) ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
On Fri, Jan 15, 2016 at 4:02 PM, Martin Koppenhoefer wrote: > Obviously we wouldn't want people to tag the whole assortment of a > supermarket like this, but due to the amount of work the risk is low. I'll agree with what you wrote, but I still wonder how you differentiate between all the supermarket types. I'm thinking about * in some countries supermarkets do not sell alcoholic beverages * some supermarkets sells newsletters, card, cleaning products * some chains are famous for selling 1 type of computer, smartphone, or clothes for 1 week. * the larger ones sometimes sells toys, bicycles, TVs, etc. I was planning on writing a diary entry about supermarkets, but didn't found the time yet. (e.g. on how do you map that certain areas are manned - wine, butcher, cheese, backery) regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
I am quite in favour of people coming forward to discuss the possibility of improving the iD Editor if it is causing problems. I object to the continuous use of naming new mappers as a problem. I will defend the reason for iD preventing new mappers from being given the option of inadvertently or erroneously deleting other mapper's work. At least until they understand what they are deleting. New mappers have a lot to learn. They have enough of a problem just learning how to use the tools and finding out what basic tagging is without being inundated with error messages telling them they cannot save their work because of some technical fault. Let them save their work rather than it getting lost or they get so frustrated that they give up and walk away. And believe me when I say that they are nor learning bad tagging from the iD Editor because most new mappers will not understand what just happened or that the tag is different, they will just be grateful that their work has been saved and they can continue mapping. To really understand the tagging requires a concerted study and even then it does not help. When I started a waterway=wadi was an accepted tag but within a period of three months it was deprecated by a group that did not really understand it's cartographic usage. Now we are left with intermittent=yes which does not adequately depict a dry river bed that is a natural feature but only occasionally (as opposed to regularly or seasonally) has flowing water. Throughout the arid countries we now have these features (wadi/ouadi/arroyo/dry gulch/ etc.) without an appropriate tag. So I would say, do not knock the new mappers, this area is a minefield of correctness ... or incorrectness as the case may be ... and we do not want to discourage new mappers. I sympathise with the frustrations of the very experienced mappers/taggers/renderers but we have to remember that Openstreetmap has developed and grown with everyone being a new mapper at some stage. Please be tolerant of the new mappers so that they can grow with us and become the experienced mappers of the future... with our help not our criticism. Please all have a Happy Mapping year and help this immense undertaking to grow. -Original Message- From: moltonel 3x Combo Sent: Friday, January 15, 2016 2:26 PM To: Tag discussion, strategy and related tools Subject: [Tagging] Please don't think name_1 tags are errors. Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638 where the mapper thought that name_1 tags were typos. That user is on a key typo fixing spree, which is a good thing in itself, even if mistakes happen. But I wonder if some people know about the iD editor behavior below, and assume that a name_1 tag must have been created that way ? If so, consider this email as a reminder that the _N suffix is used on purpose by many people. As always, contact the mapper if unsure. On 09/01/2016, Hakuch wrote: **iD-Editor problem** unfortunately, the iD-editor is creating such prefixed tags and is training newbies to use them as a good tagging practice. When you use the raw-tag-editor and tries to add an already existing tag, iD does not throw any error or information but adds the tag with a suffixed number like _1 or higher. It suggests to the unexperienced mapper, that this is a usable method to add multiple values, although this suffixing is only made to prevent the user of deleting data. We still couldn't convince the developer, that this suffixing method leads new mappers to bad practice (https://github.com/openstreetmap/iD/issues/2896). ___ 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] Please don't think name_1 tags are errors.
Kieron Thwaites wrote: > Whichever iD developer thought that adding random _N suffixes was > a good idea deserves to be taken out back and shot. Please withdraw that comment. Advocating violence to people is not funny. You might want to say a _feature_ should be taken outside and shot, but don't extrapolate it to a person. Being abusive to developers is not funny either. OpenStreetMap is unlikely to prosper in an environment where the (precious few) developers can expect to be abused on any random mailing list or issue tracker. Thank you. Richard tagging@ list admin -- View this message in context: http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875p5864887.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
2016-01-15 16:01 GMT+01:00 Kieron Thwaites : > Whichever iD developer thought that adding random _N suffixes was a > good idea deserves to be taken out back and shot. > maybe this kind of language is common in your cultural context, but I believe it is completely inappropriate and extremely offensive around here. Please be aware that this list is not restricted to the US but people from all over the world are participating. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
2016-01-15 15:26 GMT+01:00 moltonel 3x Combo : > But I wonder if some people know about the iD editor behavior below, > and assume that a name_1 tag must have been created that way ? If so, > consider this email as a reminder that the _N suffix is used on > purpose by many people. As always, contact the mapper if unsure. > also shop_1 tags are created that way. I wonder why you would want to add these tags on purpose. E.g. for shops the values indicate a type of shop. A bookstore that also sells music cds? Still a bookstore IMHO. A music store that also sells some books? Still a music store. Now, a store that sells both, music cds and books, and maybe dvds and posters, maybe still a bookstore, maybe a new category like a media store, not sure, would have to decide on the particular case. In a majority of cases you still can decide on one of the types and that it is. A green grocer that also sells toothpaste, detergents, toys and cheese? That likely not a green grocer any more, that's either a convenience store or a supermarket. What I want to say: a shop that is 2 shops in one might well be neither of these shop types, but a new typology. In other cases, there is a well defined shop/restaurant/bar/kiosk/... which also offers some odd service or product you might find in some but not all of this kind of business, and which you consider so interesting that you want to map the presence of it. Examples might be tobacco/cigarettes, icecream, particular soft drinks (club_mate comes to mind [1]), public transport tickets, fresh milk, etc. My solution for this is sells:foo=yes(/no/etc.) Obviously we wouldn't want people to tag the whole assortment of a supermarket like this, but due to the amount of work the risk is low. People will likely just tag the things they are particularly interested in, and that are not automatically thought of being available generally. So far the list is small ;-) [2] Now, there are also edge cases, i.e. types that are so rare that you probably won't find more than a handful on the whole globe, my favorite one is this: http://www.23hq.com/dieterdreist/photo/7089481?album_id=4242149 that's an optician who also runs a polish deli shop in the same shop (and it's the same person, one door, same opening hours, not sure if it's one business actually (on a legal level), but let's suppose for this discussion that it is). My suggestion is to map them as two overlapping shops rather than shop=foo shop_1=bar. For the avoidance of doubt you can add the same VAT identification number (ref:vatin). For names, the solution should be to use well defined name key variations, there's a whole lot of them [3], and introducing just another infinite amount of indexed ones seems completely unnecessary. Cheers, Martin [1] https://matemonkey.com/map/dealer/ [2] http://taginfo.osm.org/search?q=sells%3A [3] http://wiki.openstreetmap.org/wiki/Names ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Please don't think name_1 tags are errors.
Whichever iD developer thought that adding random _N suffixes was a good idea deserves to be taken out back and shot. While handling newbie mistakes (and teaching them the correct way of doing things) is most certainly encouraged, doing it in such a way that pollutes tagging is totally unacceptable. I completely endorse the removal of any and all *_N tags. --K On 15/01/2016, moltonel 3x Combo wrote: > Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638 > where the mapper thought that name_1 tags were typos. That user is on > a key typo fixing spree, which is a good thing in itself, even if > mistakes happen. > > But I wonder if some people know about the iD editor behavior below, > and assume that a name_1 tag must have been created that way ? If so, > consider this email as a reminder that the _N suffix is used on > purpose by many people. As always, contact the mapper if unsure. > > On 09/01/2016, Hakuch wrote: >> **iD-Editor problem** >> >> unfortunately, the iD-editor is creating such prefixed tags and is >> training newbies to use them as a good tagging practice. When you use >> the raw-tag-editor and tries to add an already existing tag, iD does not >> throw any error or information but adds the tag with a suffixed number >> like _1 or higher. >> It suggests to the unexperienced mapper, that this is a usable method to >> add multiple values, although this suffixing is only made to prevent the >> user of deleting data. >> We still couldn't convince the developer, that this suffixing method >> leads new mappers to bad practice >> (https://github.com/openstreetmap/iD/issues/2896). > > ___ > 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] Please don't think name_1 tags are errors.
Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638 where the mapper thought that name_1 tags were typos. That user is on a key typo fixing spree, which is a good thing in itself, even if mistakes happen. But I wonder if some people know about the iD editor behavior below, and assume that a name_1 tag must have been created that way ? If so, consider this email as a reminder that the _N suffix is used on purpose by many people. As always, contact the mapper if unsure. On 09/01/2016, Hakuch wrote: > **iD-Editor problem** > > unfortunately, the iD-editor is creating such prefixed tags and is > training newbies to use them as a good tagging practice. When you use > the raw-tag-editor and tries to add an already existing tag, iD does not > throw any error or information but adds the tag with a suffixed number > like _1 or higher. > It suggests to the unexperienced mapper, that this is a usable method to > add multiple values, although this suffixing is only made to prevent the > user of deleting data. > We still couldn't convince the developer, that this suffixing method > leads new mappers to bad practice > (https://github.com/openstreetmap/iD/issues/2896). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
