Florian Lohoff wrote: > Would be kind of complicated i guess. > > The point is that you have number 1..100 on a way - you edit the range > from 50-60 and insert 5 nodes than you'll have 50-65 which will have an > overlap with the ones in the database (sequence wise) so the database/api > needs to reorganize sequence numbers of nodes you didnt edit. Id say - > very ugly ..
You would get the current version of that way back when you download. A subtree can be seen as ordered; for sake of redundancy we will add the sequence of moment of serving. Using the locking assumption we could just add remove the ways that where added or removed from the relation by the fantastic model that Microsoft Research has thought out (it is not a joke) <id>.<subid>. <nds id="1.1" ...> to insert a node after the first node. <nds id="1.-1" ...> to insert a node before the first node. Now this would work out pretty well, aka server verifies that the current changeset equals the submitted changes and inserts the nodes, and reorders the index. But now what if we do have transactions; - Server based best effort, like diff does with fuzzy matching - Just tell the user you are too late this is the way now, and let your editor of choice fix the mess. Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev