Forgive me if this problem has an ‘obvious’ answer. I have looked in both the Wiki and this Forum without success.
How do I clear an ‘Issue’ which OSM brings to my attention (regardless of who created it) when actually there isn’t a problem? If I “Ignore this issue”, it comes back next time. If I follow the recommended action, it can/ will produce the wrong result on the Map.
Does the ‘Issue’ function need an option “This is not an Issue” such that the Map accepts the query it made as not relevant/ resolved without the need for action? In this case, the matter might need to be referred to an expert/ mod/ admin, who might wish to ask the Cartographer for further information.
Example: the Ticket Office at Ealing Broadway Station, London, UK, understandably, has the word “Tickets” above the sales windows. (A poor-quality photograph, sorry, but it suffices for the purpose.) In line with the instructions for the ‘Issue’ (“Names should be the actual, on-the-ground names of features”), “Tickets” is not at all a “suspicious name” for the Ticket Seller. I am offered only the options to remove the name or ignore the issue.
Removing the name would be the easy (cowardly/ wrong) way out in this instance, but I saw something similar a while ago, for a barber (I think it was), and so a general answer - a fix? - would be welcome.
If you choose to fix this problem, please say what you did, so that I, and others, will know what to do when we see the problem!
I guess I can also see why the issue exists though. “Tickets” is a very generic name, so I would personally try to see if there was another name, perhaps not displayed so prominently. Like on a sign in the window, etc.
Based on Ealing Broadway Station | National Rail you might try putting “Ealing Broadway” or “Elizabeth Line” in the name or operator fields. Not sure if that helps.
Why does a ticket office inside a station need any kind of a name? A name may well make sense for a stand-alone shop or kiosk selling concert tickets, for example, that is a business in its own right. But for a typical ticket counter inside a station I generally wouldn’t name it (or ticket machines or ticket validators). The operator field might be useful in some situations.
More generally, I just ignore issues raised by the ID editor if I don’t think they need fixing or if I don’t have the information that would be needed to fix them. I don’t know if there is a way to “remember” which errors I have chosen to ignore.
Just because a word is prominently displayed on something, doesn’t mean it is that thing’s formal name. A name=* in OSM terms is explicitly a proper noun that is something other than merely a plain-English description of the thing.
In this case, I’d say it’s pretty obvious that “Tickets” is merely a description of the counter’s purpose, and not a name per se… hence why it’s flagging it as an issue. It is correct to do so. Removing the name tag is the correct solution in this instance.
In any case, warnings about potential issues are exactly just that: hints that something might be wrong. It doesn’t replace manual verification and there might be false positives.
I’ll break with the others here and say that, while descriptive naming is bad, and this is probably on-the-line, I wouldn’t really object to this being tagged name=Tickets.
Regardless, re: non-issue Issues, @Woazboat is absolutely correct:
If your map needs a “Tickets” text label for them, you can simply do it yourself on all shop=ticket
Eg name=Toilets is useless for =toilets shop=ticket already means tickets, and there should be an icon. Clicking it in a proper app should show the category is tickets.
I concur with aforementioned inscription= for signposted title. label= may be better if it installs much info, while this may be artificially composed.
by the way, I see shop=ticket used in different contexts for different features: it is sometimes used for the entrance area of museums where admittance fees are paid, or it is used for places where you can buy concert tickets and similar, or also for places which sell bus tickets or train tickets, or shuttle bus tickets, of tourist tour bus tickets.
Woazboat and Lumikeiju have come closest so far to addressing the general, system, problem, which is the one I’d really like to be corrected. When one has done the “manual verification”, and established the false positive, it ought to be possible to mark it as such and thereby close it, so that others aren’t troubled by it.* We might want an admin/ mod to approve it, to prevent some individuals from marking a POI incorrectly, and trying to force the matter.
If the technical team can provide a solution here, it would be most welcome! Being able to clear the false-positives would trouble us less, and it would improve the Map’s stats!
In this instance, thinking of what is helpful for the average user (who may not immediately recognise what the icon represents), and remembering that the Wiki entry for shop=ticket tells us to include the name, I decided on “Ealing Broadway Ticket Office”, based on GuardedBear’s suggestion. (By the way, I discovered that “Ticket Window” is also deemed acceptable, but it is perhaps less helpful for those who lack a good grasp of English.)
* Alan_gr: Indeed, ignoring an Issue, whether implicitly or explicitly (“Ignore this issue”) isn’t remembered by the system; the Map doesn’t ignore the false positive ‘non-issue’, and continues to raise it.
Ticket Office is not a name as already mentioned earlier and it does not become a name by arbitrarily adding the name of the feature surrounding it, as clearly described in the wiki:
Constructing names is a form of tagging for the renderer. Do not construct names for features by combining the name of an enclosing or nearby feature with a description.
There aren’t really any admins or mods for map data, there are only other mappers.
(There is a Data Working Group who can adjudicate on disputes but that is a small team who wouldn’t be involved in this kind of routine decision).
I’d say that is dubious advice from the wiki, probably having its roots in the tag originally being envisaged for an actual shop rather than a ticket window in a station. It shouldn’t override the general concepts documented under the name tag that several people have already mentioned - it is not intended for purely descriptive words or for names that are invented for the sake of having a name.
Interesting, I didn’t know it was a systematic thing. I guess I just subconsciously ignore anything about names when reading the wiki (as most ordinary objects don’t require any special treatment of names beyond the general principles).
One factor would be perceived obviousness with the spatial relationship. If the shop=ticket is inside a building=train_station or =museum , it may appear clear what it’s about. (Secondarily is iD not having it as a field in the preset)
The format still needs to be agreed on. Aside from ticket=public_transport vs tickets:public_transport=yes , the mode has high needs, whether bus=yes etc are added, or changing this to eg ticket=bus somehow.
Besides, there are other possible attributes viz =direct vs =reseller , or =discount
I see a similar warning when working with Chevron’s convenience stores. They’re branded as “Food Mart” which is also flagged as suspicious. I ignore the issue because they what they are. I can’t help it that some programmer decided “Food Mart” can’t possibly be a real name.
Thanks, Pussreboots and Boocha34. It’s good to learn of other instances of the general problem.
Thanks for the tip, Boocha34. Actually, because, like Pussreboots, it seemed to me to be a technical/ programming matter, I approached the Engineers - engineering@osmfoundation.org - just after my last edit, yesterday. One way or another, we may hope for progress.
