Changes between Initial Version and Version 1 of Ticket #8509, comment 29


Ignore:
Timestamp:
2017-11-20T21:27:27+01:00 (8 years ago)
Author:
cmuelle8

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #8509, comment 29

    initial v1  
    1010  * or simply merging the datasets offline (that is if merging is able to fill the conflict dialog just as UpdateData would)
    1111
    12 A downside of doing the verification pass online is increased traffic, but an additional upside would be inclusiong of eventual changes done by peer mappers in the meantime.
     12A downside of doing the verification pass online is increased traffic, but an additional upside would be inclusion of eventual changes done by peer mappers in the meantime.
    1313
    1414Overall this employs the conflict detection engine in JOSM to keep the dataset editable, i.e. the dataset is not simply unlocked after a successful upload but needs to be merged with a new dataset (either the local duplicate or the polled data in result of UpdateData Action).
    1515
    1616It's just a rough draft, it might not be feasible to do, but it seems this has not been thought about in above discussion (or maybe I've overlooked, sorry in this case).
     17
     18If the server does not accept the changeset, this might produce additional complexity though:  A conflict object produced as a result of a failed upload might be difficult to merge to the active dataset if it involves primitives that have been changed  ("conflict hitting conflict" case).  In this case it may be better to not try to merge the dataset with the failed upload, but to issue UpdateData on the active layer instead and simply warn the user that the upload attempt failed.  I.e. the merge od duplicate and active layer dataset should only be necessary, if the upload succeeded.  So it may be harder to code than the locking approach, I suppose.