locationCompatibleWithClass() too inclusive?

[n76]

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.

[mar-v-in]

I agree that the current way to build "classes" is not very good and the system you just described might be better, but in most real environments it will not make a big difference. (the main task is to find APs that are off by miles not meters)

The calculation engine is intended to be moved to the UnififedNlpApi as mentioned in microg/android_external_UnifiedNlpApi#1, the version added there will include the way proposed by you (and will likely change a few other things, eg use a better name than "classes" 😄 )

[n76]

Once the calculation engine is moved, I think I will use it in my local wifi backend.

What is the best way to assure that a backend will fail gracefully if a user had mismatched unifiedNLP and backend(s)?

Edit: Might consider "cluster(s)" of APs rather than "class(es)" for naming in this case.

[mar-v-in]

Once the calculation engine is moved, I think I will use it in my local wifi backend.

That is the intended outcome 😄

What is the best way to assure that a backend will fail gracefully if a user had mismatched unifiedNLP and backend(s)?

Mismatched API library versions will only cause problems when the communication API is changed, not when the API library is changed. This did not happen so far. I'll also try to ensure that backward compatibility is given. Changes in the communication API will be reflected in the major number of the API library.

However, if you're interested in the communication API versions used (by service and the backend itself) you can use org.microg.nlp.api.VersionUtil introduced with API library v1.1 and UnifiedNlp v1.2.0

[ale5000-git]

Is there any update on this?