On Fri, Dec 11, 2009 at 4:13 PM, Csaba Halász <csaba.hal...@gmail.com> wrote: > > are not guaranteed to be the nearest ones. Also, I am not entirely > sure that the current cutoff distance checking is sufficient. Let's > suppose a coordinate system centered on the bucket containing the ref > point at the +,- corner. (See attached diagram) Assume bucket size 1, > requested range 1.05. So the ref point is at +0.5,-0.5. Box left > bottom bucket center at -1,-1 left top at +1,+1, distance from ref > point is 1.58 for both. That satisfies the 1.5 * 1.05 = 1.575 cutoff > condition so the code will never look at the bucket centered +2,0 > which could contain a point at +1.5,-0.5 with distance 1.
Upon closer look, not only that the code won't look at the *next* box (radius=2), it won't even look at the *inner* box (radius=1), because the cutoff check comes before processing. Clearly that is wrong. Also, the whole positioned code seems to be ignorant of the fact that buckets don't have the same size. Staying with the spatialGetClosest, it assumes it can just use NxN boxes when in fact a different row (latitude) could have half or double the bucket size. spatialFind() even uses the width/height of the current bucket explicitly. In light of this, not even the patch I proposed on IRC is halfway correct, so James please don't commit that. In my opinion, such a low-level and widely used piece of code must work correctly otherwise a lot of things can break. Thus I consider this a show-stopper for the release and an attitude of "the issue of terminating with 'not actually the closest', I know of, but don't really care about" isn't acceptable. -- Csaba/Jester ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
