On Tue, Jun 17, 2014 at 3:06 AM, Åsmund Tokheim <[email protected]> wrote:
> Sorry, but I fail to see such case - if point is close, it will be also > close on at least one of 3 planes (x,y), (x,z), (y,z) > Let's say that your table has the points (1, 1, 1000), (1, 2000, 1), > (2000,1,1) and (2, 2, 2). Unless I'm completely mistaken, a 1. nearest > neighbour search from (0, 0, 0) using your algorithm would return (1, 1, > 1000) as the nearest neighbour. The correct point should however be (2, 2, > 2), which is somewhat close in all planes, but not very close in any plane. > Hmm ... I see now the problem - I was working under assumption that correct point would be "overwritten" by bad one. But in this case - on every mapping (xy, xz, yz) - the overwrite happens by different point. Good catch, thanks. > My only concern is that the <-> operator won't use the index when you apply an arbitrary function like translate_xz to its input. It will if I'll index the function, and not the point. Regards, depesz
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
