This I suspect is a suggestion from the iD editor. That’s the default editor that you get when you click the “edit” button at the top of the screen if you haven’t explicitly chosen another editor. There are lots of other editors; see this page on the wiki and the links from there.
The team that develops the iD editor do so here, and that “issues” list is what people have already reported. There are over 100 open issues around “names”; yours may be already listed. An “open issue” doesn’t necessarily mean something that should be fixed, since (as you’ve seen above) there’s often a discussion to be had about how things should be tagged (including what name to use) in OSM.
As an aside, here are the most frequent combinations of other tags that occur with shop=ticket. Unfortunately, that list does not include “what sort of ticket”. That’s in contrast to the other in-person way of buying tickets, from a vending machine: 97% of those say what sort of vending machine they are (10% of all vending machines sell public transport tickets).
This is actually a different problem - lots of different maps exist made from the same data, and how those maps display railway ticket offices is up to them. People will argue (see above) about what the name should be, but you probably do know the operator of the ticket office? You could add that. Maps that display that sort of thing (that’s one of mine) can then show it.
(for completeness, I’m a member of that group)
Should a dispute erupt about this (and it hasn’t here) we’d probably suggest “please discuss it on the forum” (which is exactly what happened here). This wiki page explains that in more detail.
I’m not convinced that the things mentioned above (editor suggestions and changes to rendering of maps based on OSM data) are within the EWG’s orbit either. Their wiki page has more information.
Finally:
I don’t think that that is necessarily true. It’s certainly possible to imagine a shop selling other sorts of tickets having a concession stand inside a railway station. I can’t think of an example, but my local station has lots of ticket vending machines that don’t sell public transport tickets.
I had a reply from an Engineer, and he too pointed me to the github site you mentioned. Having not seen the general problem there, I have raised it (ref. 12283).
I have played with JOSM, but I found that I prefer the way iD works. (Some might argue therefore that I should play with JOSM more.)
I plan to continue with this fixup (though I would be happy if someone else would fix it, this lands on my very very very very long TODO list of OSM things)
I might hope a batch file (or similar) could be created to do such repetitive work. It’s an ideal job for a computer. Humans have better things to do (usually).
Do you think about removing name=* from these webpages entirely or just remove it out of the string “tag it with shop and name” and move it to the paragraph “Tags used in combination”.
I think the latter would be appropriate because in fact most shops do have a name.
That’s fine with me. I’ll keep that issue in my mind and update such pages whenever I come across one. I have already startet earlier to put some more attention to the name-tag mentioned on various wiki pages, specially for such objects which do not have names regularly.
The “main” section about names and brands is currently at Shops#Identity, where we could spend a few words on names and absence thereof. Actually, there is a wikicode trick (<onlyinclude>) where we could replicate (“transclude”) that content in all shop pages without creating a separate template.
We learn there that a ‘proper’ fix is not possible, because iD (currently anyway) has no means to store a false-positive flag for an attribute (e.g. name=*) of a Feature.
That thread was closed without reference to me, but we may hope that at least the words
“Ignore this issue”
can be changed to, e.g.
”Ignore this issue (applies only to this session)”
or
”Ignore this issue (for now)” ,
so as to enable the user to understand immediately that the user is ignoring it (for now), and not the Map itself.
If you use “My Edits” (which is the default setting), you will only see the issue “once”, in the session where you edit the object. Only if you feel adventurous and in the mood of fixing things around, click “Everything”, so that you get a full, often long, list of issues detected in the current viewport.
Besides, when one clicks “Ignore”, this may really be for one of two reasons: 1) the issue does not exist and should be ignored forever or 2) the issue exists, but I don’t know how to solve it at the moment (perhaps it needs a field survey).
For class 1), in some situations there is a tagging whereby you can assert the correctness of the situation. The best known is noname=yes, and there is the whole not: namespace.
Yes, I am familiar with those options, and I use the “Everything” a fair bit, to put things right where I can fix an error/ update the tags etc.
In the instance I cited at the top, you’ll have seen that noname=yes is now attached to the Feature, following Mateusz_Konieczny’s edit of the Wiki, and so we have a partial solution.
Your reason 1) was the main problem I was hoping could be solved, but now I understand it can’t be.
In the case of your reason 2), I would use a fixme for a problem of my own making - but really, I would hope to solve the difficulty/ uncertainty myself before updating the Map.
I had hoped that the technical types at GitHub might at least have taken up my suggestion to improve the user experience and understanding, with a small modification of the words in the Warning (to “Ignore this issue for now” / “Ignore this issue - applies only to this session”, say), but at least one of them (a “UX Designer”!) hasn’t (yet) understood the point.
That’s a bit wordy for the limited screen space available. I would suggest using “Skip” instead of “Ignore” – the latter is indeed unclear as to duration.
As I mentioned above, some issues are permanently fixable using e.g. noname=yes. I don’t think that iD currently suggests that as a solution. Anyway, I’ll comment to that sense in the github issue, if it’s still open.Edit: It is not. Perhaps Mateusz might reconsider, or perhaps we could create a new one.
what I would reconsider? Just in case I have not closed the issue and I cannot even close issues created by others in iD project (unlike iD tagging schema project).
maybe, though I will leave proposing it at issue tracker to native speakers or people more confident in their grasp of subtleties of English
)