views:

530

answers:

2

I have the following available:

  • last reported lat,lon w/timestamp
  • target lat,lon
  • estimated time to target
  • heading

How can I interpolate an estimated position over time?

I know that's enough to calculate the required average velocity for the remainder of the trip. Given a straight-line distance, it's pretty trivial. I know it has to do with vectors but I'm a bit rusty and thought it better to consult some experts.

The reason I need this update rate is limited, so to show smooth animation I need to guess at the current position between updates.

The target platform is a Google Maps application so I have available some basic functionality like a Geo-correct function for distance between two coordinates. Language is unimportant as I know many and can port or adapt any examples if needed. General solutions would be preferred however.


Is this simply two independent vector calculations?

latestimate = latstart + (Δlat * P)
lonestimate = lonstart + (Δlon * P)

Where:
   testimated = the reported estimated time to target
   telapsed = time since last time estimate
   P = telapsed / testimated
   Δlat = latreported - lattarget
   Δlon = lonreported - lontarget
+4  A: 
Lat_to_Travel = CurLat - TargetLat
Long_to_Travle = CurLong - TargetLong
Time_to_Travel = ETA - now

If the distances are relatively small, it is probably ok to assume a linear progression on these three dimensions (*). You then need to decide on a number of intermediate position to display, say 10, and calculate each intermediate point accordingly

NbOfIntermediates = 10  // for example    
Lat_at_Intermediate(n) = CurLat + (1/NbOfIntermediates * Lat_to_travel)
Long_at_Intermediate(n) = CurLong + (1/NbOfIntermediates * Long_to_travel)
Time_at_Intermediate(n) = now + (1/NbOfIntermediates * Time_to_travel)

The most complicated in all this is to keep the units ok.

( * ) A few considerations as to whether it is ok to assume a linear progression...
Obviously the specifics of the reality of the physical elements (marine currents, wind, visibility...) may matter more in this matter than geo-spatial mathematics.
Assuming that the vehicle travels at a constant speed, in a direct line, it is [generally] ok to assume linearity in the Latitude dimension [well technically the earth not being exactly a sphere this is not fully true but damn close]. However, over longer distances that include a relatively big change in latitude, the angular progression along the longitude dimension is not linear. The reason for this is that as we move away from the equator, a degree of longitude expressed in linear miles (or kilometer...) diminishes. The following table should give a rough idea of this effect, for locations at various latitudes:

Latitude   Length of a Degree      Approximate examples
           (of longitude) in 
           nautical miles

0          60                      Kuala Lumpur, Bogota, Nairobi
20         56.5                    Mexico city, Mecca, Mumbai, Rio de Janeiro
45         42.5                    Geneva, Boston, Seattle, Beijing, Wellington (NZ)
60         30                      Oslo, Stockholm, Anchorage AK, St Petersburg Russia         

See this handy online calculator to calculate this for a particular latitude.
Another way to get a idea for this is to see that traveling due East (or West) at the lattitude of Jacksonville, Florida, or San Diego, California, it takes 52 miles to cover a degree of longitude; at the latitude of Montreal or Seattle, it takes only 40 miles.

mjv
Sorry, didn't get notified of your answer while I was adding my comment. I think we're both saying the same thing... I will accept your answer after a couple upvotes to back it up ;-)
Mark Renouf
@Mark R, sorry, myself, I hadn't seen the formulas you added to your question either. I see you are too assuming that you can use a plain linear extrapolation. See my edits regarding this assumption.
mjv
I think because I already have the estimated time (which we can assume is correct if there are no anomolies) that removes the geospatial aspect from the equation right? I'm interpolating over time to find position, not trying to calculate the time.
Mark Renouf
@Mark R, not quite so... [sorry]. Let's take a [slightly contrived] example: A plane out of Miami estimates that it'll be in Seattle in 5 hours. If you were to sketch a progress line by linear interpolation, you'd show the plane progressing west-wise, as much during the first hour than the last. However the shortest route of the plane be surch that it "does" a little more North in the early hours, and a little more West in the later hours. (effectively the plane would likely travel a more complicated routes, with several turns, because of both FAA routing policies and to take advantage of ...
mjv
... the various weather considerations in particular the location of the jet stream.) In a nutshell, the linear interpolation provides a good approximation of the projected vehicle path, but it may be off if the travel involves a significant differential in latitude. Since no vehicle really travels [for long periods] on either the rhumb line or on the great circle, this approximation may be ok. If you are tasked to provide a good estimate on either of these imaginary lines, the formulaes to apply would vary.
mjv
+3  A: 

You want to use a Slerp, or spherical linear interpolation.

Convert your latitude and longitude to a unit 3-vector:

p=(x,y,z)=(cos(lon)*cos(lat), sin(lon)*cos(lat), sin(lat))

Then, "Slerp" gives you a constant-velocity interpolation along the surface of the unit sphere:

theta= angle between 3-vectors p0 and p1 (e.g., cos(theta)= p0.p1)
Slerp(p0,p1,t)= ( p0*sin((1-t)*theta) + p1*sin(t*theta) ) / sin(theta)

Note that if theta is very close to 0 or 180 degrees, this formula can be numerically unstable. In the small-angle case, you can fall back to linear interpolation; in the 180 degree case, your path is genuinely ambiguous.

comingstorm