Android Question Animation of the google maps markers similar to the Uber application

jose luis gudino

Active Member
Licensed User
Longtime User
Hi.
I have a consult:
As you can do the animation of the google maps markers similar to the Uber application,
that is to say that the vehicle when moving does not jump, this gives the feeling that as if it were moving on the route.
Thanks in advance
 

emexes

Expert
Licensed User
Not sure why nobody's answered this, perhaps there's some complexity that I'm not seeing.

Presumably you're talking about the same type of movement as on www.flightradar24.com also.

In which case, for each moving marker, you'd need to keep track of the previous position update (longitude, latitude, timestamp) and its velocity (longitudinal and latitudinal), and then when a new update comes in:
B4X:
NewTimestamp = DateTime.Now

Dim DeltaTime As Float = (NewTimeStamp - OldTimestamp) / 1000
If DeltaTime < say 5 seconds then
    LongitudinalSpeed = (NewLongitude - OldLongitude) / DeltaTime
    LatitudinalSpeed = (NewLatitude - OldLatitude) / DeltaTime
End If

OldTimestamp = NewTimestamp
OldLongitude = NewLongitude
OldLatitude = NewLatitude
and then in a separate timer tick routine (every second or so), you'd update the marker positions like:
B4X:
Dim CurrentTime As Long = DateTime.Now

for each marker do
    Dim DeltaTime As Float = (CurrentTime - OldTimeStamp) / 1000  

    If DeltaTime > SomeTimeoutPeriod Then
        'if no updates for a long time, remove marker from display  
    Else If DeltaTime < SomeValidPeriod Then
        Dim CurrentLongitude As Double = OldLongitude + LongitudinalSpeed * DeltaTime
        Dim CurrentLatitude As Double = OldLatitude + LatitudinalSpeed * DeltaTime
        'update marker position on map
    Else
        'marker should already be on map, but we're not getting updates, so leave it at our best guess of current position
    End If

Note that:

- Longitude and Latitude should be stored as Double, not Float
because a Float gives 24 bits of resolution = 1-in-16M = 3 metres resolution at equator etc, which is a bit borderline for our purpose.

- The check on DeltaTime in the position update code was to prevent speed from being calculated for the first position update (when you don't have a previous position). But... now that I think about it: even if you did do the speed calculation, you'd have a humongous DeltaTime and thus the speed components would be close enough to zero to not cause a problem, and even if it did, it'd resolve itself within seconds when the next position update arrived.

- Unless you are plotting UFOs or meteors or some other super-high-speed object, then you can side-step all the spherical-to-cartesian math, because the mismatch between the two will be negligible between your position updates, and the error will be reset each update anyway ie it won't accumulate and cause trouble.

Hmm, maybe the prospect of having to do that spherical geometry is the reason for no replies.

:)
 
Upvote 0

jose luis gudino

Active Member
Licensed User
Longtime User
hi, Fantastic!!!
Thanks for your time and for your answers, it helped me a lot.
yes, it is exactly like the same type of movement as on www.flightradar24.com.
just like you think it has some complexity or
although I also think that it can be a "loop" of movement, and this is simulated between two points. so that the feeling of movement is given
Thank
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
It just occurred to me that you might need to watch out if you're plotting courses in the part of the world where the longitude wraps around between +180 and -180 (or 0 and 360, or whatever scale your positions use) degrees. Although I expect that thin problem area of the world is mostly ocean anyway and, again, the situation will resolve itself with the next position update.

One solution is to assume that you're not moving more than one degree per position update, and thus you can just use the fraction part of delta-longitude and delta-latitude when calculating speed components.

Even more simply, just don't do the speed calculation if delta-longitude or delta-latitude is outside of the range -1 .. +1. The previous speed is probably a good-enough estimate of the current speed, and again again, the situation will resolve itself with the next postion update.
 
Upvote 0

emexes

Expert
Licensed User
yes, it is exactly like the same type of movement as on www.flightradar24.com.
FlightRadar24 is a ripper site to look at when thinking about how to do this. Click on an aircraft and you'll see its trail, with the position updates showing as dots. When the aircraft turns (eg near airports), you can see the estimated position continues in a straight light from the last position update, and then when the next position update comes in, you can see the last segment of the trail move from estimated to actual.
 
Upvote 0
Top