locationCompatibleWithClass() too inclusive?

Because locationCompatibleWithClass() returns true if any AP currently in a class is close to the AP being checked, wifi APs spread out with spacing just under MAX_WIFI_RADIUS may result a set of APs that could be kilometers apart. Perhaps locationCompatibleWithClass() should only return true if the new location is within the desired radius of ALL the APs currently in the class rather than just one of them.

Not sure what combineClasses() is/was supposed to do but I suspect that if you create one class for every AP before actually doing the current work in divideInClasses that you would end up with one of the results being optimal. There would, of course, be many classes with duplicate members but selecting any one of the duplicates should not be an issue. Worst case with N APs would be N classes each with N members. I suspect that N is usually << 100, probably on the order of 10, so it should not be too big a memory or processing load.

Start by locating locationCompatibleWithClass() and divideInClasses(), then trace how combineClasses() is used. The issue proposes changing the compatibility rule and reconsidering class construction, but names no files or tests; done requires agreeing on the intended class semantics and validating them with regression coverage.

Written by the indexing model from the issue text.