On Mon, 11 May 2009, Matt Amos wrote: > the changeset is not affected, and persists, but none of the changes > in the uploaded diff will be in it.
For sake of 'space is available' just keep the changeset and mark it as, invalid. > >> 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. > > i don't understand what you're trying to say. changesets have bboxes, > yes. they're calculated from the data, not exposed in the URI like > XAPI does. I start editing Josm/Potlatch/Merkaartor says: for the next 15 minutes bbox lat/long is locked for editing. For properties highway=* etc. The editor pings back after the period to maintain a lock. > >> 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. > > to be honest, i'm with frederik on this - if he wants diffs to be > atomic, if that makes development easier for him, then i think we > should just leave it as it is. If he gets back all what is broken, he can mark it explicitly in JOSM. And even suggest to commit the rest of the data. Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
