Implement Responsive User Location Tracking Mode

[bleege]

The User Location tracking mode (None, Follow, Bearing) was disabled in #1856 as the User Location dot was being updated on the main UI thread. The core logic is there, but it needs to be implemented in a more efficient way so that the UI remains responsive.

/cc @erf

[erf]

Could it be added as an annotation?

[ljbade]

@bleege Is the issue that there is too many events?

[erf]

i made a lowpass filter in #1968 which could be used

[erf]

in addition to some minimal time / angle diff

[erf]

I think you should move out the setDirection call from updateMap to the onCompassChange event.

[bleege]

@bleege Is the issue that there is too many events?

Yes.

[ljbade]

@bleege How does iOS handle that?

[1ec5]

@ljbade, on iOS, MGLMapView doesn’t do anything special. But it seems that Core Location is doing a better job of coalescing location updates than what we’re using on Android: #1676.

[bleege]

But it seems that Core Location is doing a better job of coalescing location updates than what we’re using on Android

Exactly. We need to put a regulator / distance filter on updates to location or specifically that a certain amount of distance / time needs to elapse before updating the dot on the map.

[ljbade]

@bleege I recall the LOST framework has this ability to filter (certainly Google Play services do).

We still need to work in @erf's compass filter for that data.

[ljbade]

I was getting confused between location/GPS events and map position change events.

[ljbade]

In #2409 I'm cleaning up the updateMap() code so this should be unblocked by performance issues now.

[mikemorris]

Have you tried sampling input/direction (I've used a constant rate of 15-20 times per second, but we could likely go lower) instead of trying to process or filter all events? I've done this in the past for handling user input from a gyroscope and accelerometer more smoothly in JavaScript, where it was previously choking on large bursts of minor change events.

Sample code at https://github.com/mikemorris/gyrocopter/blob/master/gyrocopter.js

[ljbade]

Hmm I might have accidentally removed the user tracking stuff in #2002, but the code is still there in git history so perhaps we can have a go at making it really good this time.

Lets start with just location/GPS (and heading?) tracking and work on compass after.

Should we also hit the UI side of getting our GPS dot looking better?

[ljbade]

Im thinking we eventually want a few modes (start with first two):

• no tracking
• just location tracking
• location tracking and map heading/rotation from GPS direction
• location tracking and map heading/rotation from rate limited compass

Also do we make touch events cancel tracking (separate for rotation and pan events). Or leave that up to the app via the listening events.

[tobrun]

Discussed with @bleege,
Important part here is that while zooming the GPS marker 'jitters' and shown GPS location is wrong.
If that problem is identified and fixed, I will start looking at optimising the bearing part.

[tobrun]

I'm working on this again, because I have noticed 2 bugs on current progress that need to fixed asap

[tobrun]

To clarify above:

• Spinning UserLocationView UserLocationView is spinning around  #3240
• Stop listening to bearing Stop listening to bearing when we change to state to none #3262

[tobrun]

The new camera API from @bleege will help resolve remaining issue on this ticket:

#3396 contains the fix for animated location updates with user tracking mode enabled.

Todo list to close this issue:

• do similar fix for setBearing as done for setCenterCoordinate Backport setBearing with new Camera api #3397
• improve performance/jitter UserLocationView Remove Jitter from UserLocationView #3398

[Buckley404]

Is this working correctly now?

Currently when I try to set up tracking in the onCreate it draws the blue marker in the top left corner, digging through the code on git I found that this was because the position of the marker is being set relative to the mapview by dividing width and height by 2 (height and width would be 0 while onCreate is being called).

I altered my code to include a button I could press to start tracking in order to bypass the problem, however even though the screen is centred on the correct position, the blue dot does not draw to the screen.

In the UserLocationView class and in the update method, why are you setting the blue marker position by dividing the screen/height width by 2 to find the centre point of the screen. Why not use the latitude and longitude to draw the marker like you would with a regular addMarker call or a screen centre?

If the code even worked properly, wouldn't moving around the map with user input reposition the blue dot in the wrong place i.e. keep it in the centre of the screen no matter where the user navigates to on the map?

[tobrun]

@Buckley404, reading through your comment I believe you are using the incorrect method. If you want the user location to show on the map in similar fashion as a marker you should call

nMapView.setMyLocationEnabled(true);

instead of:

nMapView.setMyLocationTrackingMode(MyLocationTrackingMode.TRACKING_FOLLOW);

Let me know if you have any other questions.

[tobrun]

#3397 landed with f80673b

[tobrun]

One thing I need to add to this is that current compass implementation is not on par with the one from Google. Current implemented code using accelerometer and magnetometer is generally spoken the accepted way of implementing a compass (as seen in books, SO and tutorials). It seems Google is adding some extra elements to the equitation or using another configuration to calculate values. One of the most notable differences is that Google's implementation is not impacted when switching perspective or tilting the device.

[Buckley404]

Thanks again @tobrun, I'll recheck my code after work however I think I was using both methods. I must have just confused myself. FYI google might just be setting minimum thresholds for when the compass should be affected by gyro.

[tobrun]

@Buckley404 I have been trying to mimic their behaviour for quite some time and I now believe that Google is doing something different than just using the sensors as we are doing.
FYI I added thresholds in latest code, we could further optimise this by implementing a low pas filter.