edit conflict is confusing for mappers

[matkoniecz]

User gets confusing message and no clear way to handle it.

I would propose to

• add note "It means that objects you edited were edited also by someone else"
• Add button "throw away edits and cached data" to provide an escape hatch for someone who is not an expert.
• maybe add hint that undoing some edits may allow to upload at least part of them
• Also, throw away cached data for this area (or all) after edit conflict appears and then upload is done (because user resolved it manually or via undoing edits until they could be uploaded) - as it is certain that GoMap data is outdated and liable to cause conflicts again

I was mapping with someone who works in IT and edit conflict message confused them, they were able to resolve it only because I realized where we conflicted. And then they run into edit conflict again because GoMap has not downloaded new data after they undo some edits and uploaded nonconflicting ones.

PS: GoMap works great for them, I finally convinced them to start mapping :)

[matkoniecz]

Yeah, resolving edit conflicts would be great but I am not even going to propose adding it without being willing to implement that.

[bryceco]

There's a rudimentary conflict resolution in place already: if you try to upload something and the server says there is a newer version then we discard your version, download the server's version, and then retry the upload. It will do that multiple times, but there are still cases where that isn't sufficient, so that's where it could be improved.

[matkoniecz]

then we discard your version, download the server's version, and then retry the upload

is it happening automatically? Or should user reupload after getting this error?

[bryceco]

That behavior occurs silently and automatically. It might be buggy or not work correctly in some cases.

If you want to try testing some scenarios on the dev server you can enter "dev" as the server URL in Advanced Settings.

[matkoniecz]

It failed in case where node was attached to modified way. Maybe this process got confused because it needed to detach node and give up on gluing it to a road?

(I cannot test it as I have no Apple devices)

That behavior occurs silently and automatically.

Maybe warning user that some part of edit were thrown away would be a good idea

(phrased as "There was edit conflict, as someone else also edited - but editor automatically rescued part of the edit!")

[Udarthegreat]

It failed in case where node was attached to modified way. Maybe this process got confused because it needed to detach node and give up on gluing it to a road?

I have an idea for how how this type of edge case can be handled, when you get an error from the OSM api that is a change set conflict on a specific way or node and cannot fix it through the silent background process you already do.

This got me thinking on a possible way to fix some of these kinds of issues, what if when you get an error from the OSM api that amounts of change set conflicts and cannot fix it through the silent background process you already do. This would require two changes

change to the popup

In the popup that comes up when there's is a change set conflict were some one has changed a node since you started the commit and refreshed the data at the end it says on which node or way (id) the error accord so it would be nice if the id number was link that when clicked would scroll the list of changed/added/deleted nodes/ways in the upload panel so that you can interact with it so that you dont have to scroll for to long through the list when you have a large change set ready to go.

Undoing the specific conflicting change

There are two ways that this can be part can be achieved as seen below:

in the upload panel

The first one would in my opinion be the better method assuming the change to the popup is implemented. The idea is to when you tap and hold on the link the changes list to have a popup menu come up that lets you remove all changes you made to the node in the commit, if as way is attached it might not work and a error pops up telling you why. Then you could just go to the attached way disconnect it and revert do the action again, its better to have the way floating there then removed or cut short since it can be easily reconnect latter by the contributor or by some one else, at least you know what is were. This is why the change to the popup above would be nice to have other then easily going to the problem node it would allow to remove the changes to the problematic node or way, especially if it was just a change to the location or data of a POI.

the change to the more button

The second possible fix to the problem would be to the more button that pops up when you select an object. The idea would be that when an object has be modified when you click on the more button you get the option to "Revert Changes" which would work the exact same doing so from the upload panel would. This would be most helpful if you have to disconnect something from a way, once the newly connected way is disconnected you can just bring the way to its current default state in the app, as if it hadn't been touched at all in the commit. This would also be useful if the user decides that they dont want to change a particular node/way but have made changes since so that they don't have to undo to the point they changed the object they no longer want to.

A few other nice things to have

• The fist would be to have a search bar in or on top of the changes list so that you can search for objects with specific names or other tags like that. So that you can find objects to navigate to on the map or revert if the revert is implemented through the first method.
• The second is that when you exit the upload panel at a specific spot in the changes list when you return to the upload panel remembers were in the changes list you were and puts you there.