|
Let's say there are two users, "M" and "N". User "N" downloads the data for an area (Which I'll call "A1") at T=0 and starts happily editing it. Some time after, user "M" downloads almost the same area ("A2"), at T=1, and edits it. At T=2, user "M" uploads the changes made (Changeset "C1"). At T=8 (that is, 6 hours after "M" uploaded "C1"), user "N" uploads his changes, creating "C2". However, "N" notes that a large part of the items he uploaded in "C2" were already uploaded in "C1" by "M". That is, the dataset used by "N" was stale and did not show "C1" changes until the moment "C2" was uploaded. Assuming that the quality of the overlapping parts of "C1" and "C2" is equivalent (very similar tracing, similar tagging, etc.) and therefore it is not possible to rule based on the quality of the data, what is the expected behaviour of "M" and "N"? If needed, I could provide the users and changeset IDs, but based only on what I wrote, what should be done? |
|
Who downloaded the data first is completely irrelevant. Depending on how much time "N" has he can either:
If you are using JOSM (looks like it as this workflow is (nearly?) impossible with Potlatch), then you should update the data from the server just before you upload, if you have taken a long time to make your edits. |
|
Just to make this clear, a problem only occurrs if both users have added new data (in which case it would be desirable for the "better" data to prevail, whatever that is). Had both users made modifications to the same existing data, the API would have reported a version conflict upon receiving C2, and user N would have to go through appropriate conflict resolution steps in his editor before the changes are accepted. |
Editing for several hours without uploading is in general at not so good idea. I suggest to upload at latest an hour after having made changes, both to keep the changesets small and to minimize such conflicts as the one mentioned above.
This advice doesn't solve your current problem, but it helps avoiding the same kind of problem in the future. For a solution, please see cartinus' answer.