Example:
We're in a train with a non-blacklisted WiFi (maybe blacklist is outdated, or maybe the WiFi doesn't broadcast SSID).
Once the WiFi is added to DejaVu DB, our location will be reported wherever we added the WiFi. If we have enough GPS accuracy and are more than moveDetectDistance (300 m) away, the WiFi will be moved to our current position, and bad location reports will continue, but with a different location.
Proposed solution:
Don't move the emitter, instead don't use emitters with radius > moveDetectDistance for location reports. Ideally there would be some EmitterStatus.STATUS_IGNORED, which is set when radius is too large, and acts similar to blacklisted, but without removing the emitter from DB. The new status would avoid useless emitter updates in DB
Further example:
Same as above, but our GPS accuracy is not enough to move the emitter (e.g. we detected the emitter at the train station, but inside the train GPS accuracy is too bad)
Now the emitter will continue being used for location reports even though we have a contradicting GPS location.
Non-blacklisted mobile emitters are moved if the bounding box is very large, see https://github.com/n76/DejaVu/blob/e54aae2d9f3d4619065a258b431ace1911d1e931/app/src/main/java/org/fitchfamily/android/dejavu/RfEmitter.java#L509-L514 but in some (I suspect many) cases the emitter keeps moving, and thus we keep moving the emitter position in our database.
Example: We're in a train with a non-blacklisted WiFi (maybe blacklist is outdated, or maybe the WiFi doesn't broadcast SSID). Once the WiFi is added to DejaVu DB, our location will be reported wherever we added the WiFi. If we have enough GPS accuracy and are more than
moveDetectDistance(300 m) away, the WiFi will be moved to our current position, and bad location reports will continue, but with a different location.Proposed solution: Don't move the emitter, instead don't use emitters with
radius > moveDetectDistancefor location reports. Ideally there would be someEmitterStatus.STATUS_IGNORED, which is set when radius is too large, and acts similar to blacklisted, but without removing the emitter from DB. The new status would avoid useless emitter updates in DBFurther example: Same as above, but our GPS accuracy is not enough to move the emitter (e.g. we detected the emitter at the train station, but inside the train GPS accuracy is too bad) Now the emitter will continue being used for location reports even though we have a contradicting GPS location.
Proposed solution: Loosen the requirements in https://github.com/n76/DejaVu/blob/e54aae2d9f3d4619065a258b431ace1911d1e931/app/src/main/java/org/fitchfamily/android/dejavu/RfEmitter.java#L494 e.g. to
gpsLoc.getAccuracy() > ourCharacteristics.reqdGpsAccuracy || gpsLoc.distanceTo(<center of emitter>) > moveDetectDistance + gpsLoc.getAccuracy() + <some padding to be sure>. Then the bouding box will be increased to an "unbeliavable" size and the emitter will not be used in location reports (if upper solution is implemented)(related to #33 )