The main question is how often will you make queries against one set of points.
If you are going to find one closest point in the set once, then @Lucian is right: you can also leave the points unsorted and perform a linear search to find the desired point.
If you will make a relatively large number of requests against the same set of points, it is advisable to organize point data to increase the speed of the request. @izomorphius already mentioned the kd tree, and this is definitely a good suggestion. Another possibility (admittedly quite similar) is the oct-tree. Between them, I find oct-tree a little easier to understand. Theoretically, the kd tree should be a little more efficient (on average), but I never saw much difference - although perhaps with different data the difference would be significant.
Please note, however, that creating something like a kd tree or an oct tree is not very slow, so you donβt have to make a lot of queries against many points to justify building it. One request clearly does not justify it, and two probably will not, either, but contrary to what Lucian suggests, O (N log N) (for example,) is not very slow. Roughly speaking, log (N) is the number of digits in the number N, so O (N log N) is actually not much slower than O (N). This, in turn, means that you do not need a particularly large number of queries to justify the organization of data to speed up each of them.
source share