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

Discussion in 'Android Questions' started by jose luis gudino, May 1, 2019.

  1. jose luis gudino

    jose luis gudino Member Licensed User

    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
  2. emexes

    emexes Well-Known Member 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 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:
    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:
    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
    '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.

    jose luis gudino likes this.
  3. jose luis gudino

    jose luis gudino Member Licensed 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
    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
    Last edited: Jun 6, 2019
  4. emexes

    emexes Well-Known Member 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.
    jose luis gudino likes this.
  5. jose luis gudino

    jose luis gudino Member Licensed User

    Thank you for your time I will try, excellent explanation :)
  6. emexes

    emexes Well-Known Member Licensed User

    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.
    jose luis gudino likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice