Frederik Ramm napsal(a): > Hi, > > JOSM does not upload changes in the order you made them (because this > would probably cause an unnecessary amount of uploads for various > steps of your local edit history). > > This is all fine, but every now and then uploading stops due to a > network failure or so. JOSM then clears the whole command/undo history > because logically the *changed elements* that have been uploaded are > something completely different from the *change actions* visible > there, and you have no chance to find out which actions have been > "uploaded" and which haven't (some might be partially uploaded even).
Well, I can (if I try harder) make the modified state independent of undo queue clear. On every primitive upload, its modified state will be cleared so partial upload would leave the rest of primitives marked as modified and upload them correctly later. If you undo an already posted change, the undo operation could mark the primitive modified again (not currently implemented this way), so subsequent uploads would behave correctly. This would also need correct handling of the visible flag: 1. new Node (id=0, action=add) 2. Upload (Node.id = whatever server returns, action: none (!modified)) 3. Undo (mode marked modified/deleted) 4. Upload (Node marked !visible,!modified) 5. Redo (modified, visible, id still from the server) 6. Upload - can I reintroduce a deleted node through the REST API? Please note that in (3) the undo system won't physically return the data set to the state before (1). It would do a logical return - keep the node and mark it as deleted. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
