Resolve conflicting edits when uploading - Esri/arcgis-osm-editor GitHub Wiki
Between the time you download data from OpenStreetMap, make the edits locally and then submit the changes back to the OSM server, other OSM users could be working in the same geographic area and submit the changes just before you. As a result, you might encounter a data state which is different from the time when you initially downloaded the data. In that case, the OSM server might reject your upload and indicate a conflict. This appears as an error description in green font color in the geoprocessing dialog window (or if background processing is enabled, it is possible to check the geoprocessing results window - see http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Using_the_Results_window/002100000013000000/).
To mitigate the conflict, the ArcGIS Editor for OpenStreetMap offers a Conflict Editor. Open the Conflict Editor by activating the OpenStreetMap toolbar, as shown below. Note: To enable the Conflict Editor button, you need to be in an active and open edit session.
Once you enable the Conflict Editor, you will see a window similar to below.
In the top left of the Conflict Editor window is a list of datasets and their noted conflict. In this example there is one downloaded dataset called seattle_osm_revision in the current map. This one dataset has one type of conflict with respect to a line feature. When you hover over the node, a tooltip with the conflict description will be shown.
The top right section of the conflict editor shows the attributes of the local feature (edits that were made on the local machine) and the attributes of the feature as the OSM Server currently sees it. In our example we have a race track in downtown Seattle and the local version has the name 'OpenStreetMap First Edition'. However due to the popularity of the race track someone had already changed the name to 'OpenStreetMap Second Edition' and submitted the changes back to the server. This change now causes a conflict because the server assigned the already-submitted changes the version number 2 whereas our local attributes still refer to version 1.
In addition to the attribute change there was also a change in the geometry of the feature shown in the bottom area of the Conflict Editor. The geometry of the local feature is shown on left side and the geometry on the OSM server is shown in red on the right side. The colors (green for local and red for server) are fixed but the symbology derives from the default drawing symbology settings in ArcMap.
You now have to choose which information is accurate and should be kept: the local attributes (“OpenStreetMap First Edition”) and the local geometry (green line) or the server attributes (“OpenStreetMap Second Edition”) and the server geometry (red line). Right click on the listed error and choose one of the suggested solutions for this error. In the screen capture below the user decided to keep the server attributes (highlighted in green for the attribute table) and the local geometry (green check mark for accepted in the left map and red cross-out for rejection in the right map for the server geometry).
Not all conflicts have a resolution associated with them, and there are always two entries to revise the state of the conflict itself. The first option, Reset the current revision status, clears the conflict status but leaves the error description in the database. It is then up to you to determine a conflict resolution based on the description before the data can be submitted back to the server. The second option, Remove the revision incident removes the conflict altogether so that the local state of the feature becomes disassociated from the server feature they are no longer influencing each other.
Back to: Documentation