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
Lat_to_Travel = CurLat - TargetLat
Long_to_Travel = 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.
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.
来源:https://stackoverflow.com/questions/1739019/how-to-use-linear-interpolation-estimate-current-position-between-two-geo-coordi