Maarten Deen wrote: > You will have to keep the whole way > for the off chance that you zoom out in the editor or really want to edit the > whole way (like splitting it).
You don't have to, there is nothing preventing edits that happen in the middle of a way. The problem only occurs at the cutpoints. If a user is prevented to edit that your solution is there. Even then fetching that small bbox, or really request the way in full, is just a request away. Don't make partial stuff more complex than it is. The editor reads any non-continuous list of integers as 'out of bbox'. For example the following returns: nds idx1 nds idx2 nds idx4 nds idx5 nds idx8 The editor will now render 5 nodes within the viewing area. It will even highlight these when a way is selected. But it will on render lines between 1..2 and 4..5. Spitting between them is possible. Extending/moving of endpoints is not possible. A variation to this would be that the first node and last node (have to be marked as last) is always extendable. The edits are pushed back the server with the algorithm mentioned in a few mails a go, Microsoft used this for XML updates. Edits between two nodes will be marked as 2.1, 2.2, 2.3 and 4.1, 4.2, etc. Algorithm to merge it would them be compare the two fixed begin and end integers (if they are at the same position), if so merge the float edits between them. Pitfalls are ofcourse inserts before the first observed node, which can be compensated by looking up for the first instance of a nodeid. Since a node id is only allowed one time in the list. If this node is still at the same position, likewise for the end node, we can safely merge everything between it in order. Stefan _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
