Stefan de Konink wrote: > If you can agree that this tag/nds out of order thing could be the > main reason for these strange inserts, I am happy to help you > search for the source that reflects this.
I have an open mind as to what it might be. > For some reason I think that the actual API call to update a way > (hence: new timestamp/user) *is* done first from a code > perspective, but is not finished when the request is done for > current tables vs history tables. If you say 'but i create an xml > and PUT it too' /way/<id> like anything else, then that is very > interesting situation and you maybe right we are looking for the > wrong editor. For its transport format, Potlatch uses AMF rather than XML. Speed is vital in an online editor, like Potlatch (or, indeed, the original applet). When using Flash, AMF both saves bandwidth and serialisation/deserialisation time. http://www.jamesward.com/blog/2007/04/30/ajax-and-flex-data-loading-benchmarks/ will give you some benchmarks. (Plus, of course, it doesn't suffer from the memory leaks that we seem to have with Ruby's XML handling.) amf_controller.rb then takes these AMF messages, and calls exactly the same Rails methods as the XML API does. I would strongly recommend you look at the code that saves ways: http://trac.openstreetmap.org/browser/sites/rails_port/app/controllers/amf_controller.rb#L330 FWIW, my experience is that data inconsistencies of this sort happen mostly when the server is under very heavy load. If a process is killed halfway through a write operation, then obviously you're going to get some sort of inconsistency. You can order the operations so that this is less likely (cf http://trac.openstreetmap.org/changeset/13184/), but as has been said here extensively, this kind of stuff is always going to happen without transactions. Richard -- View this message in context: http://www.nabble.com/Re%3A--OSM-talk--Handling-of-towns-with-different-or-alternative%09names-tp21697397p21705144.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
