This seems to be a case of setting your expectations unrealistically high.

I am “watching” recent changesets in my area and contacting contributors, when something seems fishy or sometimes simply very different from what I know how it looks like on the ground, this isn’t the case of old changesets. As soon as the history shows, that the changeset is several months/years old, there is, IMHO, a reasonable expectation that the situation has changed in the meantime. For this, I am simply correcting / mapping the new reality, without contacting anybody.

In my experience, if you don’t catch the change within the first two or three months, it is too late in the big picture. I am/was active in HOT-OSM projects, and I find myself somewhat puzzled, when somebody contacts me about changeset more than 2 years old. I am even sometimes asking why is the person even contacting me now. How can you remember why did you map something this way and not the other one? How is the person even looking at the same aerial pictures or situation on the ground?

Even on recent changesets (few days old), it is sometimes a simple difference in the opinion how to map, and both could be perfectly valid. There is no way you can “protect” your entries. You can ask why the change was made but often, the only reason is simply different point of view. If you feel very strongly, you can ask that the changes are reviewed/reverted. In most cases, the result will be “It is not as bad as you see it, can stay as it is”. I wouldn’t revert without discussing it at least on local list. And I wouldn’t get into edit wars with the other contributor, this way lies the madness and vandalism.

If the changes are hurting the map, then yes, be prepared to go as far as the top of the OSM-food-chain and put a request for a revert. If you are not ready to make the effort, to explain your reasoning and show why it should happen, the new change in the map is not as bad as it seems to you.

That is a longstanding problem, I had put several issues into the old bug tracker for Mapillary.

What I suggested: Upload the sequence without their processing, change locations of some run-away photos or change the view direction in case it gets interpreted wrong. For fully manual processing, just after this manually mark the blur areas with their app and then put it in the processing queue. This would be the most logical one if you are going manually process your own photos. For automatic processing, just confirm that the sequence has the orientation/position OK and should now go into the “area recognition” first - where cars/street/etc. are recognised. And leave the blurring process after this - and run detection for the faces just where there were people detected, license plates just where there were cars detected, other privacy probably just windows in houses. Mapillary detects all these parts, and almost flawlessly as well.

What you got: Upload, wait for processing. Change view for the sequence, wait for processing. Move some photos, wait again for it to register. Go to the blurring/deblurring process. At every photo, delete all the blurs, and do your own, because it is faster this way. You had to go one photo after another, you could not skip to the next blurred one to get it all in one go. Take a “quick” view on the finished sequence, blur what was missed.

Mapillary was generating immense load on their own servers for no reason, just because they have the processing sequence the wrong way around.

Not sure if the current process is still the same - I stopped to put my photos there and just use the sequences I take privately for my local edits. I have simply lost my patience with the Mapillary app on web.

The Mappilary plugin is a useful tool - but beware, in some places the road sign detection is mostly wrong, there are too many false positives detected or some signs are recognized wrong, showing a different one then there is on the ground.

Unless something happened lately, there is no way just yet to correct it in Mappilary itself and the downloaded photos overlay the wrong sign in the picture. I am not sure if there is a way to see the unprocessed image in JOSM. This means you cannot see the correct sign hidden under the falsely recognized one.

@SimonPoole Agree, but what I meant to say is - get somehow the “pre-sifted” users from the mobile platform, the new users who started to map like this and are still mapping after some time, who didn’t stop after getting the few shops/pubs/houses in and left again. And get them up to the next level from mapping simple POIs. In the large number of users of mobile apps, there are some (tiny, tiny percentage) who stay, but who won’t be looking for more by themselves. And these would be good candidates if we could reach them.

It might be that the type of people who become long-term mapper isn’t the same as the type going to a mapathon if you look at the majority of the participants. Mapping is somewhat solitary activity, and a mapathon is here more of an exception than a rule. You cannot expect people looking for a crowd when they are doing something to continue on their own - they will go and find another community project where all the work is done this way. You get perhaps a few people here or there, but most of them would miss the crowd.

And most people are tugged in too many directions - the long-term mapper is a rather rare sight everywhere. The odds are stacked against getting somebody like this from a mapathon. It is the same as getting long-term mapper from a user you recruit through a mobile app - just the total number of users is much higher there, giving you a better chance thanks to this. It might be a time to start looking at a mapathon not as a venue where you go looking for completely new mappers, but as an opportunity to get the already mapping newbies (the new mappers from mobile apps) to learn more, to introduce them to another form of mapping. The problem still stays how to get these in.