`rtree.nearest` documentation wrong? about rtree HOT 9 CLOSED

Thanks for your comment. So the fact that it does get returned in order is
really an implementation detail that I don't want guaranteed by the api so
that if I want to I can change it. I don't think that the method name
'nearest' implies that it should be returned in any order so on that basis
I think the doco is valid.

On 25 February 2015 at 16:14, Dustin Spicuzza [email protected]
wrote:

Looking at the implementation of rtree.nearest, it states that it returns
objects in no particular order. However, it looks like the comparator that
it uses is called ascendingDistance... I haven't actually tested this of
course, but was wondering.

—
Reply to this email directly or view it on GitHub
#19.

from rtree.

So if I wanted to guarantee that they were returned in order, then I suppose I would add the comparator again -- just in case the implementation detail changed?

An alternative is you could add yet another overload with a boolean 'sorted' that does guarantee some type of order, and one that doesn't.

I think that 'nearest' with a count should make some guarantee about ordering. It would be difficult to imagine (though, certainly possible) something that returns the N nearest without checking somehow that they are in fact the N nearest. Presumably to determine that ordering it would have to be sorted somewhere, so why not pass that on to the caller?

from rtree.

I think your last point is good. I'm happy to change the doco to guarantee ordering.

from rtree.

thanks for your contribution @virtuald

from rtree.

Thanks! This is a super useful library.

from rtree.

@davidmoten sorry for bringing this up again, but it appears that nearest does not in fact return results sorted by distance -- even though the code appears to use a sorting comparator. Perhaps this is why the original docs state that the results aren't sorted?

It's confusing to me, but when I print out e.geometry().distance(searchBounds), I get print outs that look like this:

==
0.0
0.23379993438720703
0.2892003059387207
0.0
0.12929964065551758
0.0
0.24679994583129883
0.1872999668121338
==

This makes me wonder if it's actually returning the nearest results... I'll try to get a localized example of this working.

from rtree.

Ok, so you're using a MinMaxPriorityQueue underneath the hood, and the iterator returns results in no particular order --- so, therefore, your original comment on the code was correct. Very interesting.

It makes sense to me why it's done this way. However, it would be nice to have a version of the nearest method that does return them in sorted order. Presumably could just add a method that uses a different type of container to hold the results.

from rtree.

from rtree.

0.5.8 has the fix.

On 26 March 2015 at 07:28, Dave Moten [email protected] wrote:

Hi Dustin

Thanks for that, I hadn't noticed the documentation on the iterator saying
no particular order (perhaps I noticed first time around!). I think I
should modify the use of that queue so that on completion I don't use the
iterator but rather poll the queue which should return in order. That
should fix things. I'll raise an issue on github and we can continue
conversation there so rtree watchers can be aware of issue.

Dave

from rtree.