[OSM-dev] ROMA servers down - osmosis large way problem

D Tucny d at tucny.com
Wed Dec 31 07:28:51 GMT 2008

2008/12/31 Stefan de Konink <stefan at konink.de>

> 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.

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...

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...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081231/238bb5a3/attachment.html>

More information about the dev mailing list