And someone has already missed the point and “resolved” the issue 
1 Like
https://mapillary.com/map/im/804066108026097
The name looks to be mapped correctly, the smaller text is descriptive not part of the name.
When I first reverted it from a pub I checked the history and certainly trust the previous mappers.
1 Like
sounds like we need a brand:wikidata=no tag.
well, technically single standalone shop also has a brand
There is some usage of no:brand=yes for off-brand or unbranded stuff. I suppose that’d be one way to indicate an independent shop, but I wouldn’t be surprised if there are already other tags for that.
no:brand:wikidata=yes on the other hand would mean that it is part of a brand, however small, but there’s no Wikidata item about it. I’d probably avoid tagging the nonexistence of a Wikidata item, because it could easily get out of sync when someone decides to create an item about it on Wikidata.
2 Likes
I have completed the revert of UK edits by this mapper.
There were a lot of conflicts and I have tried to keep what was added
later.
Phil (trigpoint)
5 Likes
As another Christchurch NZ based mapper, I’ve just come across this thread. Trying to get my head around what to look for, and what scope of reversion might be required in NZ
I see that Mateusz_Konieczny has asked the user if they are still doing the same thing here Changeset: 165711136 | OpenStreetMap so far with no response there.
However, looking at Changesets by Numbergod | OpenStreetMap the latest is Fri May 2nd, so it does look like they have at least paused their efforts…
Looking at the NZ edits I was wondering the same thing. Turns out that Rapid has a “power user” mode where you can turn on the option to add a “fix all” button and another option to turn off the requirement that the object you are editing is visible.
I had a play around and you can pan across the map, wait for the error list to up date, and then hit “fix all”, racking up a couple of thousand edits in no time and no mouse overload.
4 Likes
Rapid needs to remove those “features” which inflict unwanted automated edits on the OSM database.
I see Rapid also adds a rapid:poweruser=true tag to the changeset, so perhaps that can be checked for as a red flag for potential automated edits to revert.
2 Likes
Note that Rapid is not developed anymore.
is “power user” having any other use that is not basically an undiscussed bot edit?
I suspect not.
1 Like
It feels like this thread has gotten pretty uncivil.
I’m not sure whether there are moderators even watch this forum (I haven’t seen any evidence of this), but the knee-jerk reactions and attacks on Rapid have gotten out of hand, and I’d prefer for people, particularly @rskedgell and @Mateusz_Konieczny and @trigpoint to take a step back and consider whether your comments are really helping this community.
Obviously if a user is misusing the tool, you should try to communicate with them using the established processes, rollback their work, suspend their account if they are really damaging the map.
All validators can raise false positives, and users should not map for the validator. The Fix All feature is similar to features that JOSM and other editors have to perform tag fixes. Users should only use this feature with a subset of map that they feel comfortable reviewing visually.
Furthermore, the power user feature is opt in - so @numbergod needed to enable it and use it more broadly than they should. The power user flag does enable other features besides fixing lots of validations - it unblocks preview datasets, operations on larger geometries, and some other stuff. It is not for “basically undiscussed bot edits”, and to suggest such a thing is disrespectful. As mentioned earlier, Rapid will flag the changesets with a special tag, so that their edits can be watched more closely.
2 Likes
If it’s true - and having the facility to accept hundreds of multiple QA “upgrade” suggestions without prior discussion or individual review of changes is - then there’s no disrespect in politely criticising it.
Accusing people clearing up the resultant mess of a knee-jerk reaction, on the other hand absolutely is disrespectful.
5 Likes
Can you be more specific which comments in this thread were harmful? (especially that I made)
Major difference is that JOSM enables it only for quite blatant cases where risk of false positives is really, really low.
Osmose, EveryDoor, StreetComplete, GoMap!!, Vespucci and iD as far as I know have no “apply all guesses and suggestions” button at all.
Especially applying guesses based on NSI without individual review requires checking them one by one as relatively often suggestions are broken. If there is button “apply all of them blindly” then it is unusual and harmful feature without equivalent in editors known to me.
7 Likes
The options available are:
Show preview datasets: Preview datasets are still in review and not available for all users
Tag-agnostic road combine: Allow the Combine operation for roads whose highway tagging differs
Tag highways as Maxar: Add the tag ‘source=maxar’ to all highways
Enable fix buttons on Issue Pane: Enable the autofix buttons on Issue pane for fixing simple issues
Allow large edits: Remove the limitations about editing features that are not currently visible
It’s interesting to check out how many rapid:poweruser=true there are in combination with the “new mapper” flag on OSMCha.
Since 1st Jan 2924, there is exactly one changeset within the UK** that isn’t by the already-reverted user discussed above. That changeset adds one shop in London and does not seem at all problematic.
Worldwide there are more " tags → ‘rapid:poweruser’ = ‘true’" changes; 672 since 1st May 2025. Most recently buildings and crossings seem to be the things most added with that flag set.
** ish. The changesetMD query I’m using is:
changesets=> SELECT id, user_name, tags -> 'comment' FROM osm_changeset c, (SELECT ST_SetSRID(ST_MakeEnvelope(-11.0,48.0,2.5,61.1),4326) AS geom) s WHERE ST_CoveredBy(c.geom, s.geom) and created_at > '2024-01-01 00:00:00' and tags -> 'rapid:poweruser' = 'true';
1 Like
I hope not. Don’t shoot the messenger.
The problem is the editor/QA. The editor/QA choose to suggest a “solution”, and the user applies the “fix”, also nothing wrong with that, excepts that is usual to most users, to think or believe that the editor/QA is an authorized opinion , and that editor/QA knows much more than him about OSM, and the problem is detected only if the user is experienced in OSM and in those type or elements or has local knowledge.
Maybe iD could geolocate the user and show some suggestions only if the source IP of the user is within the area/country that it is editing, at least for some suggestions that can cause problems.
1 Like
Such a mechanism could conceivably be useful for a number of purposes, but it would potentially have some serious privacy implications. Nothing else in iD or Rapid currently allows the public to positively identify and track the user’s physical location over time, even at a country level. But that’s what would happen if the ability to interact with these validator rules were tied to IP geolocation.
Maybe i was not clear or express the feature in wrong terms. I didn’t mean the public to identify the location of a user nor track it over time. Just that the source IP could be used by the iD editor to make a decision to which suggestions will be displayed to the user in their current session. The IP would not be logged or used to validate a changeset or in validator rules, but just to decide whether or not display a suggestion to the user based in the bbox being edited and in the geolocation of the user.
AFAIK this is shouldn’t need or imply to storing IP of the user or revealing it to anyone. The server already knows the IP as the user is using iD.
E.g. supposing you are connected from San Jose area, the iD editor could show you some suggestions when editing there, and editing the same location it should not show the same suggestion to me, because my ip is geolocated too far away. It’s is not meant to restrict the editions, as I could edit the same as you or any other user, just that iD will not show me suggestions assuming I’m to far away and not being capable of properly evaluate if the suggestion is valid, and showing the same suggestion to you, under the assumption that you are a local mapper and could make a better decision.
1 Like
The challenge with that is that geolocation can be pretty unreliable, especially on desktop PCs. Even if we’re only trying to answer “which country am I in”, people using corporate resources to connect might appear to be in all sorts of places, and people using VPNs for whatever reason to connect might appear to be wherever they want to be.
It’ll work a bit, but I’m sure there would be issues.
Taking it a step further, and taking the UK as an example, if you want to geolocate the difference betweek England and Scotland is basically impossible. It might be useful if iD could offer some different presets in England to Scotland, but whatever the network provision, that’s unlikely to be possible.
1 Like