Talk:Tag:amenity=motorcycle rental

See the talk page of shop=motorcycle_repair rtfm Rtfm (talk) 22:58, 16 April 2017 (UTC)

I responded on the shop=motorcycle_repair talk page and the same exact thing applies here. Except to add that often times where motorcycle:rental=yes was added to shops they were completely different brands and took up separate areas of the buildings. For instance with most American Harley-Davidson retailers they rent motorcycles through EagleRider. Which often has a separate office on the side of the store and that using a namespace instead doesn't allow the mapping of. I'd also echo here what I said in shop=motorcycle_repair about this tag compared to a namespace scheme being vital for non-Western, non-English speaking editors. Extra namespaces in this case just complicates things and they aren't used for this really outside of Europe anyway. We shouldn't add extra barriers to people editing by going with namespaces for their own sake, instead of adopting intuitive tags when we can that integrate well with already existing ones. It's much easier for everyone (especially non-English speakers) to understand this and shop=motorcycle_repair. Compared to 15 namespaces on a single object, that aren't needed and sometimes don't make sense. --Adamant1 (talk) 10:25, 20 June 2020 (UTC)

Do you say that `motorcycle:rental=yes` namespace should not be used, because non-Westeners don't understand it? I had a completely different experience in Asia. The tag `amenity=motorcycle_rental` was not clear. I understood that `amenity` is used to mark building type. However, in Asia it is not uncommon to rent a bike in a grocery store. And there are usually several shops in the same building. There should be a way to mark those "shops" in a building, and tag functions for each shop. For that, `motorcycle:rental=yes` tag with namespace is more logical. As it specifies available function of the place, not its primary purpose. --Abitrolly (talk) 17:16, 20 June 2020 (UTC)

Yes I do say that. My comment on the shop=motorcycle_repair talk page expands on it more then I feel the need to do here. The main gist though is that in most cases these namespaces tags aren't being used to specify the available functions of a place anyway, because the vast majority of the usage are no values. Even in cases where they used to map the available functions of a place though, the secondary function should just be mapped as a separate node. That's what the guidelines say to do and how we do it in every other case. Plus, mapping the function as a separate node keeps other important information from not being left out.

Also, it's never just one namespace. Even if the place has one available secondary function. People often clump them together by including unnecessary namespace tags, because there's a one size fits all and all or nothing mentality about them. If people just tagged a place as motorcycle:rental=yes if that's what they also do and left it at that there wouldn't be as much of an issue, but that's what they do. There's an endless amount of possible no values, there's no standard for when not to use them, and anyone who disagrees with listing every possible thing a place doesn't do is argued with, called a vandal or troll, and reverted.

Even short of lists of multiple things on a single object can become impossible to understand or manage. For both mappers and map consumers, non-Western or otherwise. More so though when they aren't what the map consumer is looking for and in non-Western/non-English speaking countries. Where they are often not technologically literate and already struggle to map even extremely simple objects correctly. Even when presets are involved and they are using a single tag. That's just reality. Think about how hard this is to follow and it's only at three paragraphs.

BTW, amenity is used to mark objects useful to tourists. It's not really anything to do with building types. Amenity means "a desirable or useful feature or facility of a building or place." Which is why there are amenity tags for vastly different real world objects, like amenity=bank and amenity=bench. In this case motorcycle rental is an amenity tag because tourists often rent motorcycles. Unfortunately, those kinds of details are lost with namespaces. Which causes everything to be homogenized into an over simplified, purely descriptive label. --Adamant1 (talk) 23:03, 20 June 2020 (UTC)

Are you sure it possible to use `motorcycle:rental` tag without value? I though values are obligatory. Where do you look the stats that show tags without values? Being non-Westener from Belarus I find it hard to validate you claims about non-Westeners. Sounds a bit like racism, you know. Hopefully you have the stats to backup your beliefs.

Creating another node just to assign `motorcycle:rental=yes` means you have to duplicate address, owner, working hours, etc. This should bloat to the database and lead to inconsistencies when users update one address and forget the other. Which address should they update is also not obvious. --Abitrolly (talk)

Where did I say to tag motorcycle:rental without a value? My whole point is to not use it at all and to map a place as two separate nodes instead. One with shop=motorcycle and the other with this tag. That doesn't involve motorcycle:rental at all. It's just a duplicate unnecessary tag and it's usage goes against the guidelines anyway.

Claims of racism are a common re-frame by people on the internet who just want to get their way and have no better argument. That said, I have almost twenty thousands edits at this point, a ton of which are to businesses all over the world, and I do a lot of work with the back end stuff for mapping brands. Some of the icons and colors in the style on the main site are thanks to me also. So, I more then know what I'm talking about. Since I deal with this stuff all the time and people talk to me about it all the time. Even without that though, all you have to do is look at most places in Africa, Asia, or India to see that POIs are mapped extremely badly there. Way more then in Europe or America. It's not just random.

100% it's due to low education levels generally and around technology. Plus the lack of access to it. It's also exactly why most editors have presets. So people who don't understand this stuff don't have to deal with the particular of tags. They didn't randomly implement presets because everyone everywhere gets it. It's just reality that people from a place like Africa, that has a high school education level under 40 percent, will tend to get it less then people from somewhere like Europe where it's almost 80% in some places. It's not racism to say so either and I'm perfectly fine we saying we should make things as simple as possible for people who don't understand computer programming, GIS, or the fundamentals of SQL. Last I checked, it's a map for everyone. Otherwise, the creators of iD Editor must be racist for trying to simplify things. They aren't simplifying it mainly for silicon valley tech bros or the European intelligentsia. Seriously. I swear people advocating for namespaces are like a cult. They are never able to discuss facts, pros and cons of namespaces, or guidelines, and always resort to personal attacks. It's pretty ridiculous.

Re "duplicating addresses etc", It's not explicit that we have to duplicate things. There's already many places out there where the address is on the building and not the node and there is no guideline that says it has to be done otherwise. Even if some information gets duplicated anyway, it's still less bloat then the alternative of using namespaces. Especially since like I said before a lot of times service departments have different contact details and hours then the main store. Which is inherently left out by using the namespaces instead of mapping the object as a separate node. I think your priorities are off if your more worried about a duplicate address every now and then you are about not being able to add the different contact details and opening hours. There's plenty of examples of where that has happened due to usage of the namespace. Stuff like that degrades the map a lot more then a duplicate address once in awhile ever would. Anyway, it's what the guideline says to do. If you disagree take it up with the mailing list or something.

Talking about bloat, in order for motorcycle:rental=yes to be used instead of this tag on places that don't sell motorcycles it always involves five or six extra tags to clarify things. Including an extremely obtuse motorcycle:sales=no tag. Simple logic dictates that amenity=motorcycle_rental is less bloat then shop=motorcycle + motorcycle:sales=no + motorcycle:parts=no + motorcycle:clothes=no + motorcycle:repair=no + motorcycle:rental=yes + etc etc etc. Which is exactly why I say namespace advocates are like a cult, because they are to busy backwards from their own conclusions that namespaces are gods gift to everything to reason out simple things like 5 tags are more complicated and more bloat then one tag. There's never any reasonably sound counter argument to any of my points of why namespaces for this are a bad idea either. --Adamant1 (talk) 06:19, 21 June 2020 (UTC)

You say about namespaced tags without values in this phrase - "The main gist though is that in most cases these namespaces tags aren't being used to specify the available functions of a place anyway, because the vast majority of the usage are no values." and I read that literally - that it is possible to use the keys without values. I had to edit Tags page to clarify that values are obligatory. If I read the word "value" as "benefit", then the phrase reads to me "namespace tags are not specifying places functions, because using them has no benefit". Which again doesn't sound like an argument one can prove.

For the phrase "Where did I say to tag motorcycle:rental without a value? My whole point is to not use it at all and to map a place as two separate nodes instead. One with shop=motorcycle and the other with this tag." you say not to use the tag motorcycle:rental at all and at the same time to use the second node with it. Which point is correct

In the last post you also say that the usage of `motorcycle:rental=yes` is against the guidelines. Can you point to the guidelines?

As for the racism topic I need to put stress out the importance of data to validate everything people say. People are biased by default. There can be many reasons why countries are badly mapped, but you choose arguments that suits your assumptions about how the World functions. I have a good understanding of CS, SQL and GIS to some degree, although I had no idea that "value" is non optional. I came here from probably the best mapped country in the World, and even we at some point have to deal with the national security law almost made collecting and publishing vector data a criminal activity. The main driving point in OSM mapping is 100% the community - not the technical education level you are so fixed on. For example, China has a lot more STEM graduates than US, but if community fails to organize itself, there would be no map. Can you confirm that China is mapped good?

"Even if some information gets duplicated anyway, it's still less bloat then the alternative of using namespaces." - sorry, I don't get how a duplicating address info in additional node is less bloat that not duplicating it. We are talking about "motorcycle:rental=yes", which I really needed while being in Asia. If you need to map a service department working hours inside of motorcycle shop, it is quite different from mapping a location where you can rent bikes. If working hours of motorcycle shop, service department and the bike rental are different, I understand that you can always create as many nodes as you want, but then you have to copy the address to each of them, and if one address changes, I see no way how to sync changes in addresses of motorcycle shop, service department and bike rental located in the same building. Please, explain that.

"in order for motorcycle:rental=yes to be used instead of this tag on places that don't sell motorcycles it always involves five or six extra tags to clarify things" - I can't accept this argument. Sorry. I don't need the "motorcycle:sales=no" on a grocery store that rents bikes. Saying that I need this to "clarify" things, or that I need to add "shop=motorcycle" is an example of the bias or assumptions about other people that I referenced before. In the end as a newcomer to OSM I must add that your war against namespaces would be more constructive if you could backup your the personal experience with data/prooflinks rather than appealing to authority. Because I am not convinced. --Abitrolly (talk) 18:24, 21 June 2020 (UTC)

By no values I mean tags like motorcycle:rental=no. But also no as in "it imparts no useful information." Like motorcycle:sales=yes being used along with shop=motorcycle_sales. We already know the place sells motorcycles due to the shop tag. So the namespace doesn't add anything. 65% of the motorcycle:sales tags are used that way and I'm sure everyone would agree it's not beneficial. Just like it wouldn't be to tag amenity=toilets and toilets=yes on the same object. 10% of motorcycle:sales usage is a no key (value, or whatever you want to call it). While it's fine to tag an object like a restaurant where there is a general presumption that it will have a toilet with toilet=no, it wouldn't be OK to do so on something where there is no presumption like amenity=post_box (or where it's ambiguous like natural=tree). Most (or all) cases of motorcycle:sales=no are tagged in that way though. For instance here where it was being used as a work around along with other no tags like motorcycle:inspection=no so the object could be tagged shop=motorcycle instead of shop=clothes.

There's also 111 uses of motorcycle:sales=used (or 15% of the total) which IMO should be tagged second_hand=yes. If you combine all three of them (motorcycle:sales=yes, motorcycle:sales=no, motorcycle:sales=used) your left with only about 124 (or 10% of the total) legitimate or "beneficial" uses of motorcycle:sales. That's without even getting into the discussion about if they should be mapped as separate nodes or ones that are being tagged as a "service" on objects that mainly sell motorcycles. Also, those 851 (or 65% of the total) uses of motorcycle:sales=yes were all added by RTFM (ti-lo) in an undisclosed mass edit in 2017 to artificially boast the usage numbers of motorcycle namespaces. Otherwise, they probably wouldn't even be a thing right now. I know the discussion is about motorcycle:rental, but all the motorcycle namespaces are being used in the same way.

Although, the problem isn't specific to namespaces. I've dealt with the same things with other tagging schemes like rental=, sales=, etc etc. But namespaces are the ones that come up, have the mass-edits, cult mentality, and specific guidelines about how to (or not) use them. For instance the whole "Over-spacing" section of Namespace covers this and makes it clear that namespaces like motorcycle:sales=yes are the wrong way to use them. It also says ""The possible benefits of introducing namespaced keys must be weighed against their disadvantages." It's clear there are more disadvantages of going with a namespace instead of normal tag in this case. No one in their right mind would argue that there it's more beneficial to use a tag where most of it's use just duplicates data, or lists things that don't need to be listed (like that a clothing store doesn't provide motorcycle inspections), is better then the alternative.

I have zero problem with you using a motorcycle namespace in your unique edge case. Where amenity=motorcycle_rental mapped as a separate doesn't work better. Nor do I have a problem with the 1% of cases where it's actually being used that way. But that's not what this discussion is about or how it's being used in 99% of cases. This discussion is about going with the motorcycle namespace instead amenity=motorcycle_rental (and for that matter shop=clothes, shop=motorcycle_repair, and every other case where a tag is slightly related to motorcycles) and there just isn't a justification or advantage to doing so. Except in extremely rare instances that aren't even worth discussion, being talked about, or that anyone has a problem with. Like an address maybe not being copied over. Which can happen with anything and is just a normal part of regular quality assurance. There's nothing unique to motorcycle shops about it.

Addresses rarely if ever change anyway, and when they do its caused by bigger issues (like a military or militia overthrowing a government) that's already going to cause a massive amount of problems to OSM that will have to be dealt with. Or maybe a border changing but that doesn't happen enough to out weigh the cons of namespaces. Maybe you could say the guidelines about when to use namespaces is an "appeal to authority", but there is a reason they exist. Is it really beneficial to force map consumers to find what they are looking for by making them read through a huge listing of things that they aren't looking for? I'd so no and I think everyone would agree with me. Part of the problem here is that there is no standard for what motorcycle:whatever=no/yes values (or whatever) shouldn't be listed, when enough is enough, and the no options are practically endless. You don't have that problem with the alternatives like a Semi-colon value separator, because it forces you to only list what the place does.

Re, "racism" I agree things have to backed up by data, but that includes your original comment that it was racist of me to say that people who can't read English have a harder time reading English so the unnecessary tags with English words the better. There isn't an empirically data driven way to prove it's a racist comment and it goes without saying that since I don't speak German I would be able to contribute to a German opensource project that uses German words sparingly. That's not intrinsically racist. It's just reality. Although, I do have a lot of experience working on the name-suggestion-index where people have done opened a ton of issues and PR to have entries changed to their "native" language from English or to just get rid of the English language entry altogether if we can't translate it for some reason. While some of that is due to a perception (that I agree with) of English language imperialism, it's likely also due to it just being easier to have brands translated to the main language where they are being mapped. Even with icons. I don't know what else it would be. I'm not going to blame it all on anti-English sentiment. Although, maybe it is.

The problem with defaulting to racism is that people will just read your original comment, assume what I said was racist, and not read my explanation or our discussion about it. For all anyone knows though, I could have made the comment out of just pure ignorance (which isn't racism). Because I was replying at 4AM, was really tired and not paying particular attention to how I phrased things, or any other number of reasons. There's also suppose to be an assumption of good faith. Which it seems is far to often ignored by contributors to this project. BTW, I'd also strongly disagree with your reading that saying something about Africa or "Asian countries" has anything to do with race in the first place. Plenty of European descended whites live in Africa and its not like there's a single "African" race anyway not including them anyway. Not all "Asians" are the same race either and I didn't say about a specific Asian group. You brought up China. It is racist (or at racially based) IMO to treat everyone occupying those regions as a homoganious racial group that someone must be referencing when they use the word "Africa" or "Asia" though. --Adamant1 (talk) 05:10, 22 June 2020 (UTC)