You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 > 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.
if ((gpsLoc == null) || (gpsLoc.getAccuracy() > ourCharacteristics.reqdGpsAccuracy)) {
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)
Non-blacklisted mobile emitters are moved if the bounding box is very large, see
DejaVu/app/src/main/java/org/fitchfamily/android/dejavu/RfEmitter.java
Lines 509 to 514 in e54aae2
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 > moveDetectDistance
for 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
DejaVu/app/src/main/java/org/fitchfamily/android/dejavu/RfEmitter.java
Line 494 in e54aae2
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 )
The text was updated successfully, but these errors were encountered: