Non-blacklisted mobile emitters are moved if the bounding box is very large, see
|
// Bounding box has increased, see if it is now unbelievably large |
|
if (coverage.getRadius() >= ourCharacteristics.moveDetectDistance) { |
|
Log.d(TAG, "updateLocation("+id+") emitter has moved (" + gpsLoc.distanceTo(_getLocation()) + ")"); |
|
coverage = new BoundingBox(gpsLoc.getLatitude(), gpsLoc.getLongitude(), 0.0f); |
|
trust = ourCharacteristics.discoveryTrust; |
|
changeStatus(EmitterStatus.STATUS_CHANGED, "updateLocation('"+logString()+"') Moved"); |
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.
Proposed solution:
Loosen the requirements in
|
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)
(related to #33 )
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 > 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
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 )