<br><div class="gmail_quote">2008/12/31 Stefan de Konink <span dir="ltr"><<a href="mailto:stefan@konink.de">stefan@konink.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Don't make partial stuff more complex than it is. The editor reads any<br>
non-continuous list of integers as 'out of bbox'. For example the<br>
following returns:<br>
<br>
nds idx1<br>
nds idx2<br>
nds idx4<br>
nds idx5<br>
nds idx8<br>
<br>
<br>
The editor will now render 5 nodes within the viewing area. It will even<br>
highlight these when a way is selected. But it will on render lines<br>
between 1..2 and 4..5. Spitting between them is possible.<br>
Extending/moving of endpoints is not possible.<br>
<br>
A variation to this would be that the first node and last node (have to<br>
be marked as last) is always extendable.<br>
</blockquote><div><br>That would be quite nasty, seeing node 8, but not having a line connecting it anywhere? For rendering, that would be pretty useless, for editing it would be a pain in the bum, especially if there was a node 9 somewhere else outside the bbox... To get the useful nodes 7 and 9, you'd either have to get the whole way as a seperate request and then get the nodes, as seperate requests or make guesses as to which direction and how far away those nodes are and do bbox requests... You'd need at least a one node buffer around 'in box' nodes to be of use for anything... i.e. if only node 10 is within the bbox, you'd need to return 9 and 11 too, at least, even if they are outside the bbox... in your example, that would return nodes 3, 6 and 7 too...<br>
<br>To me, this feels like a significant overcomplication with no significant benefits... Far easier would be to just limit the size of ways... Hmm, I'm sure that's been mentioned already...  <br></div></div><br>d<br>