On Mon, 11 May 2009, Matt Amos wrote: > > But is the transaction aborted? If so it could never be resolved :) > > the transaction is rolled back if any element in the diff upload > cannot be committed. calling it "aborted" is a bit harsh ;-)
Then the actual changeset is persistent, even not applied? > >> > In anycase; I think what should happen is a resultset upon closing of > >> > the changeset that would show you the conflicts. > >> > >> As documented in > >> > >> http://wiki.openstreetmap.org/wiki/0.6#Diff_upload:_POST_.2Fapi.2F0.6.2Fchangeset.2F.23id.2Fupload > >> > >> information about the first conflict only will be returned. > > > > Ok this is *bad*; because I assume this is based upon a failure instead of > > a check. What imho should happen is an active check for the records begin > > inserted and preferably gracefully remove changes that have been applied > > already if they have the same outcome. > > well... it fails a check :-P Don't go grammar on me :P > what you are suggesting is complicated. at the moment the server keeps > it simple by saying "if you're trying to update an element and your > version number doesn't match the most recent, thats a conflict which > you must resolve." this is the same policy as SVN - the server rejects > all conflicts and leaves them to the client (sorry, frederik and > richard ;-) ) That is just bad, because if you go this far, then I suggest the client should bbox the changeset in 0.7 by XAPI style (this gets you layers aswell) and the bbox/props will not be given out. > it might be possible, however, to catch the error in the diff parsing > routine and continue with the next element of the upload, returning > the error in the diffResult. bearing in mind that the second or later > errors may be caused by previous errors, if this behaviour is > preferable to the client devs then it can be changed. I think you could use the OSM Fixer query style to check the actual differences. But might be better to start a different thread on this. Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev