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: [email protected] [mailto:[email protected]] 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 [email protected] ## N49°00'09" E008°23'33" _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
