I agree and it is very unfortunate that a lot of hard and well-intentioned work may be lost.
I feel the size of the changesets causes the biggest problem here. Most of the QA suggestions made by Rapid/iD/Osmose will be correct, but if you have a changeset with many hundreds of objects changed you can never be sure you’ve checked everything. With a much smaller changeset, a problem may be spotted and fixed without having to consider reverting the whole changeset. Obviously it does help if the user interacts with changeset comments.
The rate at which tools accept QA suggestions is also something which might benefit from being limited. On 2025-04-24, they changed 1341 objects in about half an hour, then another 1450 a quarter of an hour later. I don’t think I can operate a mouse that quickly, but that clearly isn’t enough time to review whether the proposed change is appropriate. I’m not sure what would be a sensible value, but it’s a lot longer than ~1600ms.
Some proposed changes might benefit from an “Are you sure?” confirmation before being applied.
Perhaps NSI could also do with a flag where extra caution with common or easily confused names might occur. There was an example above where a Chinese restaurant called Young’s was confused with the pub operator Young’s. Thankfully, Young’s (seafood) don’t operate their own shops.
That’s quite a large changeset for sure. There’s sort of an accidental limiting factor in iD in that it performs poorly once you get anywhere near that volume of changes, but Rapid performs a lot better, so there’s less incentive for someone to save early and often. Most of the ideas for limiting changeset size in editors are focused on the pet peeve that many have around large changeset bboxes. A cap on the number of changes is trickier because sometimes you really do need to start over from scratch in an area, which can naturally resolve a ton of warnings. There’s probably a more thoughtful way to incentivize smaller changesets without being draconian about it.
Part of the problem is that brands don’t have any aversion to choosing a common name. (The worst in my book is “Bench.”) There’s an ongoing effort to narrow the scopes of NSI’s brands to the countries and regions in which those brands operate. Young’s is now scoped to England, which should at least stop this brand from spreading abroad unintentionally. Within England, iD and Rapid are suggesting this pub operator on the Chinese restaurant, which is arguably an editor bug. Sometimes the food-related amenity=* tags are unclear to mappers, but cuisine=chinese should be a giveaway that something with amenity=pub is irrelevant.
Similarly, there seems to be a problem with the London public transport entries in NSI or the code to match them in iD. For example, this Tube station has seen some back and forth because of these successive warnings:
I have no idea why it’s conflating the Elizabeth line with the entire London Underground system.
By the way, clicking “Tag as not the same ‘Young’s’” will add not:brand:wikidata=Q8057802, which will silence the warning and prevent the incorrect upgrade once and for all. As values of not:brand:wikidata=* percolate to the top of the list, they help NSI contributors detect buggy entries, and then it becomes possible to remove those tags without causing editors to mislead armchair mappers. Of course it’s better not to have bugs in the first place, but this is a failsafe for the bugs that do arise.
The way the question is asked is extremely loaded; the mapper is given literally no information about why iD is suggesting a tag change and no information about what the change actually means, it instead talks about “upgrading” the tags when what is actually happening here is actually nothing of the sort - the hard work of actual surveying mappers is being destroyed.
Or maybe not. It may be a perfectly logical tag combination in the part of the world where the mapper is from.
Certainly in the part of the UK where I live amenity=pub and cuisine=Indian is certainly a thing (as I remember one I missed which also has no real ale so I won’t be going back).
One idea could be to not perform NSI/iD “upgrades” in parts of the world the mapper is not familiar with, but sadly this insight is lost on many contributors…
Sort of. amenity=bar and amenity=pub did get split into a separate “match group” – which also includes amenity=restaurant. So although Young’s, the family-friendly ice cream parlor,[1] no longer gets upgraded to Young’s, the age-verifying pub, a Chinese restaurant can still get mistaken for something decidedly more beverage-focused. Absent changes to the editor’s own matching logic, NSI would need to split up the brands/amenity/restaurant file to distinguish by cuisine, which could get messy, since many chains specialize in multiple cuisines.
To state the obvious, the suggestion is an upgrade if it’s right and a downgrade if it’s wrong. If iD were totally sure it’s right, there’d be no reason to ask. So I guess the “looks like” is doing too much work here in the interest of brevity. Maybe what could help is for the explanatory text to give a good reason why you might choose the “Tag as not the same” option.
Fair point, though for NSI the consideration will be more nuanced: is it common for large chains of pubs to serve Indian or Chinese cuisine? If so, cuisine might not be a good enough differentiator.
I’ve heard good things about this dairy’s ice cream and corn maze. ↩︎
At this point I personally believe the OSM norm should move to a 7-day block on sight for applying “suggestions” without thinking, and How Did You Contribute? should give a large negative score for any block as a penalty for breaking data. Maybe then mappers will sit up and take notice, and maybe then mappers will pressure iD/NSI to “upgrade” iD’s “features”.
Because I’m sorry but performing a tag “upgrade” every 1.6 seconds is a mechanical edit, and those are not allowed without extensive consultation. It’s time to start enforcing that prohibition. Right now it’s faster to break things than to discuss how to fix them. So this kind of issue will just pop up again and again.
I don’t know if the mapper in question has How Did You Contribute bookmarked, but in my personal opinion, this tool is a major part of the problem. iD’s validator isn’t applying warning-related changeset tags so that HYDC can gamify them. It was supposed to be about helping reviewers triage individual changesets more efficiently, irrespective of the mapper’s identity. I’m sure some mappers focus their energy on validator warnings in order to achieve a green checkmark inside iD in their area of interest, but many others are treating the global reduction in validator warnings as a goal unto itself, just as we also see from the mappers who treat the notes system as their personal global Inbox Zero.
I am not a native speaker so review of text would be welcome
old:
message: “{feature} looks like a common feature with nonstandard tags”
message_incomplete: “{feature} looks like a common feature with incomplete tags”
new:
message: “{feature} may or may not benefit from changing this tags”
message_incomplete: “{feature} may or may not benefit from adding this tags”
Cuisine is a red herring here. iD should not propose changes to “main tags” as an upgrade. Even when the object tagging is “obviously wrong”, some head-acratching is needed trying to guess what the original mapper really meant.
This is a wider (and harder to solve) problem than just brand / wiki* logic.
Understood, but id-tagging-schema treats cuisine=* as a sort of iterative refinement of amenity=restaurant etc. with a more specific set of presets. This reflects that “Chinese restaurant” is a different kind of thing than “pub”, even if “pub” and “restaurant” can be interchangeable in very general terms. Or maybe not – if you select a Chinese Restaurant and switch to the Pub preset, it does keep the cuisine=chinese tag, so maybe that’s already recognized as a distinct possibility.
I support accounting for human factors in the design of this warning. However, we should avoid the problem the wiki often makes, obfuscating the language to the point of saying nothing objectionable and nothing informative. Then we’d have a bigger problem on our hands as even careful users make more mistakes. If we expect the user to make their own informed decision, we should continue to offer a prediction, but we should also inform them of the major criteria and caveats, not unlike in a well-written MapRoulette challenge prompt.
iD gets a lot right. For example, there is a prominent ‘changed objects’ count that slowly gets redder and redder at around 100 changes, and t some point it starts complaining that the user should really save very soon.
Maybe worth making the iD developers aware of this case study to highlight the what can go wrong.
Looks good to me - though “this” should be “these” in the proposed wording under “new”. Might be good to include a link to the wiki with the actual guidance too - if that’s at all possible.
Large pub chains will often tend to have a curry or a stir fry on the menu they are a long way from cuisine=indian or chinese.
Pubs sold off by breweries are sometimes becoming Indian restaurants, with the food you would expect in an Indian. They tend to still operate as pubs too.
Like most Indian restaurants they are independent so will not trouble the NSI.
I do wonder why OSM concerns itself so much with special tagging for businesses owned by the man. In any town you will get a better coffee from a cafe without a brand:wikidata tag.
