[josm-dev] Deletion conflicts
Karl Guggisberg
karl.guggisberg at guggis.ch
Mon Jun 15 19:45:11 BST 2009
Hi,
In JOSM, when you do a full update of your local dataset (File -> Update
Data), r1670 now checks if your local dataset includes
primitives which might be deleted on the server. If so, you can ask JOSM to
GET each of them individually in order to see whether the primitives
were indeed deleted or whether they were only moved out of your bounding
box(es).
In the second case the position of the primitive in your local dataset is
adjusted (or a conflict item is registred, if your local primitive is in
modified state, run the new conflict resolution dialog to resolve it).
In the first case you can select
- whether you want to "keep" your local version (in which case JOSM creates
a kind of "clone" of your version, because the version on the server can't
be undeleted)
- whether you decide to delete your local version too, in which case JOSM
purges the primitive from the local dataset. It can't delete it only
logically because the API would report a 410 Gone on the next update.
There's also a new menu item in the file menu which runs the same ops and
checks on the current selection, i.e. on an idividual primitive in your
dataset. It's restricted to 50 primitives in one step because we don't want
to hammer the OSM API with GET request.
Regards
Karl
-----Ursprüngliche Nachricht-----
Von: josm-dev-bounces at openstreetmap.org
[mailto:josm-dev-bounces at openstreetmap.org] Im Auftrag von Frederik Ramm
Gesendet: Montag, 27. April 2009 21:45
An: josm-dev; Chris Browet
Betreff: [josm-dev] Deletion conflicts
Hi,
(CC'ing Chris Browet because I'd like to know if Merkaartor has come up with
a solution for this problem that we could use!)
Shaun pointed out the following problem with conflict resolution (which
is not new, it was present in pre-0.6 times too):
> Nick downloads an area.
> Steve downloads the same area.
> Nick deletes node 23 and uploads.
> Steve changes a tag on node 23.
> Steve does an update, and does not get an update about the fact that
> Nick deleted node 23.
> When Steve uploads all he gets is a Gone HTTP status.
I see several issues here:
Firstly, Steve should not get "Gone" in the last step; he should get
whatever the usual version mismatch error code is - after all he tries to
upload his change based on an old version of node 23. This is potentially an
API bug.
But, more importantly, how could we achieve that Steve's session gets wind
of the fact that Nick has deleted the node?
Idea 1: Implement a kind of "list all objects deleted from this area within
the last X minutes" API call which JOSM could use. This would slow down the
download and increase API load but probably be a stable way to deal with it.
Idea 2: Before re-downloading an area, let JOSM mark all objects that came
from the API on the last download as "possibly deleted". On merging the
newly downloaded dataset with the existing data, reset that flag for every
object retrieved from the API. The remaining objects flagged "possibly
deleted" have been deleted on the server and should either be silently
removed, or if they have local modifications, a conflict dialog needs to be
shown.
Further ideas, comments?
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
_______________________________________________
josm-dev mailing list
josm-dev at openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
More information about the josm-dev
mailing list