Zaczero
Move "failed" changes out, then allow rest to go through
Sorry, couldn't think of a better way to describe it?
I often run a reversion on 50 CS which gets all the way through, then errors to say that "Way 1234567890 couldn't be reverted, as it needs Node 9876543210, that couldn't be found" or similar words to that effect?
Would there be any way of shifting those error reports out to "somewhere else", then allow the other 49 OK reversions to go through?
Actual wording!:
🌍️ Uploading 267 changes
🚧 Warning: Trimming revert:id value because it exceeds 255 characters:
So apparently the other 49 CS are OK, but because of this one error, the entire revert fails, requiring you to take out that one CS, then run it the revert again for the other 49, with another 2-3 minutes wait. (Yes, that's only a few minutes, but when you're reverting 1000+ CS, that well & truly adds up!)
This was with "Forcefully remove conflicting elements" ticked, but I often have the same thing with "Skip conflicting elements (assume they were fixed)" ticked instead.
So an option to say "Yes error will be removed. Would you like to upload the remaining CS?" would be great!
Couple of further suggestions for NG, in regard to this :-)
Instead of just saying "Way 123456789 has a problem", also show the CS number that has that problem.
After "Revert & Upload" starts, it runs through downloading each of the CS, then starts Generating a Revert, carries out patches & so on, then attempts to upload the changes, which is where the error message is generated. If you remove the "bad" CS, then hit Revert again, it runs through the whole thing again, then occasionally finds another error! The extra error/s should have been identified the first time around, so several CS can be removed at once, or give an option of "Would you like to remove all problem CS then continue upload?", which deletes those CS, then uploads all the rest.
The revert I've just finished uploaded 47 CS out of the 50 I started with, so I had to go through ^ 3 times! :-(
With OSM-NG, the API will not suffer from such synchronization issues and will be overall more reliable. I've already thought about detecting/skipping failing changesets in the past, but ultimately decided to wait and focus on OSM-NG, as I think it's a better use of time.
