iD editor : "Your edits look fine" - but upload fails repeatedly

Have so far used iD editor some 240 times for amendments in a limited area ; so far latest edit concerns a 500m stretch of road where a green varying-width central divider was added, cycleways away from the road, rainwater disposal via infiltration, new crossings.
‘Issues’ on the right hand side of the editing window reports “Your edits look fine”, yet find that when ‘Uploading changes to OpenStreetMap’ the process repeatedly stalls at conflict 302 of 302 … ; in Firefox in Win10 : close tab / close window / reboot : same result ; edits seem to be stored in Firefox, hence other browser won’t do the trick.
there is a message -when adding my comment- that one user has also edited the Functioneel Fietsroute Netwerk : have elected to keep their changes.

Requests :
1/ how can I step through the intended changes listed in the panel on the left to spot *what *causes the halt?
2/ in iD edit view, after pressing Save, can scroll down to bottom left hand bar to link : ‘Download osmChange file’: could that be inserted into another editor (JOSM?) to see what causes the hiccup?
3/ and finally : what’d be the most effective way to report this issue to improve iD so this error won’t recur?

Editing on other roads halted till resolved …

looking forward,

Re doing something with a saved .osc file, I’ve certainly edited and then uploaded them with JOSM. also suggests Vespucci or Merkaartor. You’ll need to edit the file to remove the data that someone else edited in the meantme (just the change to the relation I guess) and then make that change again manually.

With regard to “report this issue to improve iD so this error won’t recur” it’s not really a bug as such - if we let more than one person edit OSM at the same time, then eventually there will be conflicts, and there needs to be some way of resolving those. JOSM has a built-in conflict resolution UI which works well; it appears from looking at that iD does too. You are welcome to add an issue at , but it will only be useful if you describe a repeatable situation in which the problem occurs. In order to reproduce the problem, you could do so on the test server (you’ll need to create a new account there) to avoid causing problems with the live OpenStreetMap database.

I wouldn’t exclude this being an iD bug, as the number of conflicts seems to be far too large for the situation described. In the past there have been cases in which iD has looped trying to fix a conflict, so it could be a similar case.

In any case save your edits as an OSC file, and SomeoneElse or I can give the file a quick check if you make it available somewhere.


I’ve had a look at the OSC file and suspect the culprit is which is just asking for conflicts (right now it is 20 version older than 4 days ago).

I don’t know how iD tries to handle relation member conflicts, but it may be a bug with that.


Taken SimonPoole’s suggestion as an invite, sent WeTransfer link to him by PM - avoid more than one mapper working on same item; Simon weeded the .osc file and successfully executed the rest, for which thanks are due.

Opened each of 53 ways and 83 nodes in ‘our’ changeset and found - apart from the edit to a 3885 member relation ‘Functioneel Fietsroute Netwerk Antwerpen’ - four nodes, each at the corner of a house, where the tag bicycle=use_sidepath had been added : looks like something got mixed up there, the houses *are *along the route edited, but there was no intention to edit those houses as this edit was about the new road and cycleway layout on the opposite side than the houses are on.

This means the bulk of the changeset has now been done, and by looking at each way and node havenow completed the rest to the best of my knowledge - which will be limited as I’m a rank beginner.

Have up-delegated Simon’s suggestion to split the cycling net into more, local, relations and combine those in a super-relation to two experienced -many 1000’s of edits- mappers whom I had picked up work with City and province on mapping and cycling infrastructure; they’ve confirmed they’ll follow this up.

**Which leaves the Take Home part of this post : **

1/ it is acceptable to pan along a rural road adding miles of cycleway where there are few side roads, but

2/ in urban areas better to complete work on single intersections, then the stretches between those intersections;

3/ when working on a relation with close to 4000 members do just that one edit and upload : thus minimise chance that s/o else uploads change before you do;

4/ but please also alert the originator that the relation is growing rather large.

**Suggestions for further action / future improvements: **

iD : it would be helpful if the iD editor could flag that I’m editing a large (>1000 members) relation, suggest to save before and after editing this …

iD : it would be helpful if the conflicts could be viewed and somehow remedied : ‘ignore’ (because I didn’t survey that aspect), add a crossing, or remove that particular action from the list of edits to be carried out, then upload again;

OSM : it would be helpful if just that one edited member of the large (say >1000 members or covering over say a square kilometre of area) relation could be inserted into the database, rather than - as I now take it - uploading nearly 4k members …

OSM and each editor : is there a way to flag that a relation covers a lot : a large number of members, a large area - whatever can lead to several mappers working on the same relation at the same time, and the one who uploads last in effect loses their work, please?

Aim of the final point is to prompt the operator / originator of the relation -rather than the mapper who happens to edit part of it- to break it into manageable chunks.

With best regards / met vriendelijke groet,

hey everyone,

I’ve split up that big relation into smaller chunks, so that should already make the situation less brittle.

Sorry for the inconveniences caused!