Linear Interpolation: Need to get LAT/LONG Best answer on the web
Author:
admin
07 30th, 2010 in
xn--00t609f.com
edit
Ex.
========= (-83 Lat/ 40 Long)
*
(-84 Lat/39 Ln)
=========
Here's what I'm getting at about the three coordinates.
Pick two points on the globe. Make one the upper right corner and the other the lower left. Hopefully this makes good geographical sense so far.
Now the center of the square is the center of the square. It's not a free variable that you can arbitrarily assign. Once you choose the corner points, assuming by "square" as I said before that you mean the product of a range of latitudes and a range of longitudes, then the center of the square ought to be the midpoint of both the latitude range and the longitude range.
Of course you can pick three distinct points anyplace inside a square, if that's what you are getting at. But you seem to lable the points as corners and as the center of the square, and that's where I think we need to be careful.
Unless you are simply interested in the (spherical) distance formula between two points given by latitude and longitude, it might be expeditious to back up and explain where the data you propose to define the "square" is coming from. I might get a better idea of what role the three points you want to use mean from the application you intend to use them for.
regards, mathtalk-ga
responses to your comment:
>>The simplest conversion is to translate the X coordinate into a
>>difference in longitude and the Y coordinate into a difference in
>>latitude. If this doesn't prove "accurate" enough for your purpose,
>>then we can consider fancier methods.
-->This should be accurate enough for me for now
So, if I follow you correctly, as long as I can provide teh center lat/long, the distance in meter of the aircraft from teh center lat/long, and the bearing of the aircraft, we don't need the upper right & lower left lat/long, correct?
Since there's programming involved here, it might be helpful to give me an idea what sort of programming language is involved. Of course I'll give the mathematical formulation, but I might be able to throw in some insights about implementation techniques.
regards, mathtalk-ga
The simplest conversion is to translate the X coordinate into a difference in longitude and the Y coordinate into a difference in latitude. If this doesn't prove "accurate" enough for your purpose, then we can consider fancier methods.
The key is to determine how long a degree of latitude and how long a degree of longitude is, e.g. in meters. These lengths should be approximately constant over the region of the flight, but can vary from on part of the globe to another.
On a perfect sphere degrees of latitude (North or South) will always have the same length. This is not quite true on the Earth's globe, where degrees of latitude at closer to the poles are actually slightly longer than at the equator. This seems paradoxical to me, but several sources I've checked are consistent in giving values for this.
Degrees of longitude (East or West) will naturally vary with latitude, being at maximum length around the equator and then shrinking to zero as you approach the poles.
Now in your case the region in play is rather small, 100 km in diameter, so the first idea to check is what happens if we compute the length of a degree of latitude and a degree of longitude right at the center of the region (the origin), and then use those values throughout the flight to convert X,Y to offsets in longitude and latitude (from the origin).
Also I have some code that will compute the length of a degree of longitude and of a degree of latitude at any latitude. You'll probably want to incorporate this code into your program, although for a fixed location it would be just as easy to incorporate the resulting constants into your "terrain" data set.
I'll go ahead and post the formulas so you can take a look while I thrash out the "accuracy" of the approximation. On one hand I do not believe that accuracy in conversion is really a "stopper" for your application, because internally your program will maintain the flight location in X,Y,Z coordinates. It will not rely on converting back and forth from longitude & latitude to Cartesian coordinates, for example. So the new calculations will not introduce error into the existing positioning code.
However the mapping is only an approximation to reality, so I want to give you at some point a feeling for how the Cartesian space diverges from the curved coordinate system of longitude and latitude. For example, while changing Y if X = 0 is a true North/South motion, for nonzero values of X this is only approximately so.
regards, mathtalk-ga
It sounds partly as if you "know" the location of three points, one of which "happens" to be in the middle of the other two. For the sake of argument let's assume this does not mean an exact center point, just that it falls somewhere in the "box" of latitude/longitude values "bracketed" by the two corners.
Now you introduce a fourth point, the location of the aircraft. Missing entirely from our discussion is any information that relates the aircraft to the three (presumably fixed) locations. Are you asking how to determine the location of the aircraft by "triangulation"? I.e. given the aircraft's distance to each of the three points, use that to determine the position of the aircraft?
Such a calculation is possible, though of course with an aircraft you have a third dimension (altitude) to account for (besides latitude and longitude). I hesitate to leap to any conclusion about whether this is what you are trying to do, esp. as in your original Question the implication was that a vehicle was travelling along a "predefined path, at a constant velocity" with defined beginning and ending points.
regards, mathtalk-ga
Now, you said, it dosen't make sense to assign a lat/long to the center of the terrain, and also the upper right and lower left....I don't understand why....if we use my example lat/long as above, center lat/long can be dayton, and the upper right maybe some where near cleveland, and lower left can be around evansville, indiana..... These three points would be within our "square", I hope this made some sense....
Also, let's assume that we don't talk about velocity, how would you calculate your exact location somewhere within this "square" from our lat/long of center,uppper right, and lower left locations?
Thanks
See the material posted as a Comment at bottom on how to determine the lengths in meters of a degree of latitude or of longitude anywhere on the Earth's surface. As previously noted, these lengths are functions of latitude.
Grouping the length formulas there will allow me to formulate an Answer that focuses on the somewhat tricky points of relating the (artificial) Cartesian coordinates in which your flight simulation "lives" to the curved coordinates of latitude and longitude.
regards, mathtalk-ga
Lat = X^2 * a0 + Y^2 * b0 + X * Y * c0 + X * d0 + Y * e0 + f0
Long = X^2 * a1 + Y^2 * b1 + X * Y * c1 + X * d1 + Y * e1 + f1
and the reverse
X = Lat^2 * a2 + Long^2 * b2 + Lat * Long * c2 + Lat * d2 + Long * e2 + f2
Y = Lat^2 * a3 + Long^2 * b3 + Lat * Long * c3 + Lat * d3 + Long * e3 + f3
Ok, as you can see this is a system of six equations with six unknown, and the coeficients ( a0...f0 for LAT, a1...f1 for LONG, a2...f2 for X and a3...f3 for Y) must be solved with some samples of data (LAT and LONG for some X and Y chart points) and a matrix solve method like Taylor.
To get some accure, yo must know at lest the lat and long of six points over the chart (five near the borders and one near the center). This meassure can be made with the media of the collected readings of a steady gps in each point (more readings and more samples, more accure).
I was waiting for some feedback from you on the level of detail given in the formulas, posted below as a Comment, for the length of a degree of latitude or longitude in meters (as a function of latitude).
Assuming you are okay with formulas of that nature and the distinction between radian and degrees as units of angle measurement, I think the complete Answer to your Question can be given.
Let a "base point" for the flight simulation be given as:
Lat_base and Long_base
and use the value of Lat_base to compute the length of a degree of latitude in meters (at this "base" latitude). Note that the length of a degree of latitude is a slowly varying function of latitude; from a minimum at the equator to a maximum at the poles, the length of a degree of latitude varies only by about 1%. Its variation over a 100km stretch (a bit less than one degree of latitude) is correspondingly even smaller, on the order of 0.01%.
u = latlen(Lat_base)
Now consider the position of the "airplane" during flight in Cartesian coordinates (X,Y,Z) measured in meters from the base point (0,0,0). Here X can be interpreted as the true East (for positive values) or West (for negative values) and Y as the true North (for postivie values) or South (for negative values) only "instantaneously" at the base point. In "flattening out" the curved surface of the Earth in the immediate (50km) neighborhood of the base point, we are treating the world as flat. This not only affects the altitude approximation Z (by ignoring the "over the horizon" curvature), it also introduces small errors of approximation in dealing with X and Y coordinates as being at right angles. At the base point this is valid, but as one moves East or West (with increasing or decreasing X), then the lines of constant X will no longer align perfectly with lines of constant longitude. After all the lines of longitude (great circles) do intersect at the poles, where in Cartesian coordinates two lines of differing constant X values would be parallel and never intersect.
So the accuracy of the following formulas depends not only on the smallness of the 50km range set by the flight simulator, but also on staying relatively far away from the poles. To the extent that your software will be used at locations in Australia or the continental United States, this will not introduce substantial errors of approximation.
Then, given the Y coordinate of the airplane in flight, we have an "updated" latitude:
Lat_updt = Lat_base + Y/u
where u is given above, the length of a degree of latitude in meters. Note that this formula provides the updated latitude in degrees. To convert the fractional part of the degrees to minutes and seconds, if that suits your purpose of display, then express:
Lat_updt = sign(Lat_updt) * Lat_updt
Degrees(Lat_updt) = floor(Lat_updt)
Minutes(Lat_updt) = floor(60 * (Lat_updt - Degrees(Lat_updt))
Seconds(Lat_updt) = 3600*(Lat_updt-Degrees(Lat_updt)) - 60 * Minutes(Lat_updt)
Note that the last formula allows for a fraction part in the seconds; you would of course need to round this, probably to a whole number, for display purposes.
With this updated value Lat_updt of latitude, we would next calculate the length of a degree of longitude in meters, again appealing to the formulas cited in the Comment below:
v = longlen( Lat_updt )
Note that we are taking the precaution by computing the length of a degree of longitude from what might have calculated at the base point using Lat_base. The reason for this is that the change in length of a degree of longitude is relatively more important than the change in length of a degree of latitude.
To illustrate this effect, let's take the flight range as lying between 49 and 50 degrees of latitude.
Now the length of a degree of longitude varies to a first-order approximation with the cosine of the latitude. Therefore as a percentage difference we would see across the given range from 49 to 50 degrees of latitude (either in the Northern or Southern hemisphere):
longlen(50 degrees)/longlen(49 degrees) ~ 98%
That is to say, the length of a degree of longitude can change by as much as 2% across even this fairly narrow range of latitudes. This effect is greater the farther we are from the equator (the nearer we are to the poles), so again we should probably limit the application to points on the globe that are not much closer than this to the polar regions.
However by using this "corrected" value of v taken from Lat_updt, we obtain good approximations to the updated longitude from:
Long_updt = Long_base + X/v
The conversion of this updated longitude from a "fractional" value of degrees to a "whole number" display of degrees, minutes, and seconds would be done in the same manner as described for the updated latitude. Note that the use of positive increments for East and North, negative increments for West and South, is a standard but not the most convenient arrangement for computations in the Western or Southern hemispheres. In your implementation you may wish to take advantage of any simplification that may ensue from assuming that flight path will never switch from one hemisphere to another!
* * * * * * * * * * * * * * * * * *
Summary of formulas:
u = latlen( Lat_base )
Lat_updt = Lat_base + Y/u
v = longlen( Lat_updt )
Long_updt = Long_base + X/v
* * * * * * * * * * * * * * * * * *
Some final comments concern the use of degrees versus radians. While the output of the formulas above is nominally in degrees, we must be compatible in how we implement the formulas described below for latlen and longlen.
All that is required for this is to use a version of the cosine function that accepts angles in degrees as arguments. In the particular programming language that you are using:
http://caad.arch.ethz.ch/info/maya/manual/Commands/functionalCmdList.html
such a function can be called by invoking cosd( ) rather than cos( ) where needed. Alternatively you will see that the constant of proportionality from degrees to radians is supplied by the MEL language, so that you could also write an expression in the form:
cosd( A ) = cos( deg_to_rad A )
If additional clarification of these formulas would be helpful, please use the Request Clarification button to alert me to that.
regards, mathtalk-ga
Ok, let me try go clarify again my question, i'm sorry i'm not being concise enough.....maybe the term "square" is throwing us off....
Let me give some background on why I need help with this..lat/long stuff. We are working on a training-simulator at work in which an aircraft(s) will fly through a simulated terrain. To stick with my previous example, let's say that this terrain is the entire state of ohio, and now to the lat/long points..... Now let's select 2 points on this terrain, the upper right corner of Ohio(some where near Cleveland lat/long), and the lower left corner (somewhere near Cincinatti lat/long). Now I pick a 3rd point to resemble a point somewhere half-way inbetween these two, and let's say we pick Columbus OH, which happens to be in the middle of our other two points..so now we have these three points located inside a "imaginary" square-box, i hope you know what I mean.....
Now we have three points......using the lat/long of ONLY these three points, is it possible anyway to figure out(I assume mathematically) where exactly in terms of latitude/longitude where an object(our case an aircraft) is located within our entire "terrain(ohio)"... In reality if you know the upper-right/lower-left cordinates, you can get the upper-left/lower-right cordinates from the others....correct?
You are right, I am not looking for a distance between any given lat/long points, I need an answer in terms of lat/long, and I believe in our system, I can get the distance of where an object is located in meters from the center lat/long point, if that may make things any easier to solve this issue....
Maybe i'm asking for something that is not possible, but if you could give it a shot, I would apperciate it!
I am using a Graphis program called Maya by AliasWavefront, and I use MEL(Maya Embedded Language), it's a scripting language very similar to c++....If you want you can check the link below, and check out some of the math functions that are available that I can use, if it can help you in any way to better achieve the results...
http://caad.arch.ethz.ch/info/maya/manual/Commands/functionalCmdList.html#Language:Math
Thanks,
arunkk
Thanks again!
The picture that's emerging from our discussion is that XYZ coordinates are translatable to meters, and that the "center" of the square or box under discussion corresponds to the origin in the worldspace coordinates (or can be translated to the origin at least).
regards, mathtalk-ga
Yes, I know the starting point(XYZ) of the aircraft on the track, and ending point of the aircraft on the track(XYZ).....
I hope I didn't confuse you even more!
Regards,
A
If you are, it would not make sense to try and track in parallel the movement of the plane in longitude and latitude coordinates using "distance and heading" information there, when the same information is already available by conversion of the X,Y,Z coordinates.
regards, mathtalk-ga
Great, I think the Question is now in a form that I know how to Answer!
Since you've raised the issue of accuracy, it would help if you could set some limits on where the functions will be applied. For example, the notion of excluding the north and south polar regions has already been mentioned.
Will the flight paths be limited to the continental US?
Apart from where the flights originate, are there limitations on how far from the "origin" a flight can go? For example, will there be a need to model regions that range up to (say) 300 miles from the origin?
regards, mathtalk-ga
That's correct, although if you have the lat/long coordinates for those points as well as the X,Y coordinates, you can use them to get a (slightly cheesy) approximation to the meters per degree values we need.
Just use the difference in the corners X coordinates (which I'm assuming is in units of meters) divided by the difference in longitudes and that gives the meters per degree of longitude.
Similarly use the difference in the corners Y coordinates (again in meters) divided by the difference in latitudes and that gives the meters per degree of latitude.
Of course I think you'll find the computational approach more satisfactory, if only because it makes the set up more "portable". You (or your Customers) will not need the corner points, just the central location's latitude and longitude (which would be needed in any case to denote the origin).
regards, mathtalk-ga
It seems to me that your Question presupposes a number of assumptions that might not be supportable.
If we assume the "square plane" you refer to contains points that are assigned a product of latitude and longitude ranges, then over relatively small such ranges it may be practical to compute distances from "linear" functions of the differences in coordinates. (Your Question concerns velocity, but this is a ratio of distance to time, and the time calculation poses no difficulty.)
However I cannot see how to make sense of assigning coordinates both to the center of the "square" and to two corners. In a graphical application one would normally assign coordinates only to opposing corners, with the convention that points on the top and bottom edges have a constant coordinate in one axis and the left and right edges constant in the other axis.
Also in your example you use a latitude range of -83 to -85. If this were degrees of latitude, it would be close enough to the South Pole to produce some difficult with the "linear" interpolation of distance from Lat/Long coordinates.
If you do a search on latitude and longitude coordinates here at Google Answers home page, you will find some previous Answers that provide more accurate and applicable formulas for computing distance over the Earth's surface (I know; I wrote some of them!).
If you prefer, I'd be happy to study your Clarification to the issues raised above and give a brief Answer, commensurate with the list price offered, along the lines of "linear interpolation". These formulas would be reasonably accurate as long as the "square" patches are not extended and are not near either pole.
regards, mathtalk-ga
Only with such a context would it make sense to take the cosine of distance d.
Thinking of distance d as being measured "over the surface" of a unit sphere, the length along a "great circle" for that sphere would equal (in radians) the central angle subtended by that arc (the angle as seen from the center of the sphere between the two endpoints of the arc).
Headings on the surface of a sphere are a bit tricky. Where in the flat plane the angles of a triangle always add up to 180 degrees (pi radians), in spherical triangles the sum of angles is always greater than pi. In fact the amount by which the sum of angles in a spherical triangle exceeds pi is directly proprotional to its area.
Tiny spherical triangles are therefore "closest" to being flat!
regards, mathtalk-ga
Just checking in to see if you need any more clarifications?? I hope you have not given up on me :-)
Regards,
arunkk
Generally speaking I think the error will be dominated by positioning of the "origin" in terms of longitude/latitude. A good GPS reading is rarely able to get within 25 meters of true position, and most maps are subject to fairly systematic errors in local coordinates.
So my aim is to show that the approach I'll propose is at least comparable in accuracy to that.
regards, mathtalk-ga
*
(-84 Lat/39 Ln)
=========
(-85 Lat/38 Long)
I came across this formula, given a heading and a distance of an object from a point(lat/long), it claims that it returns the lat/long of the object....
-----------------------------------------------------------------------------
Lat/lon given radial and distance
A point {lat,lon} is a distance d out on the tc radial from point 1 if:
lat=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
IF (cos(lat)=0)
lon=lon1 // endpoint a pole
ELSE
lon=mod(lon1-asin(sin(tc)*sin(d)/cos(lat))+pi,2*pi)-pi
ENDIF
This algorithm is limited to distances such that dlon
dlon=atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(lat))
lon=mod( lon1-dlon +pi,2*pi )-pi
-----------------------------------------------------------------------------
In teh top formula for the lat, I plugged in 39(deg) for lat1, distance = 1400meters, and a radial of 80 degrees, and I ended up with an lat of .433 ?? This didnt' make any sense to me, is this correct?
lat = asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc));
.433 = asin(sin(39) * cos(1400) + cos(39) * sin(1400) * cos(80));
regards arunkk
Ignoring the distance changes caused by altitude (since you include the altitude among the "known" data now), all I can see that we can deduce from knowing the distance of the aircraft from the center point is that the plane is on a circle of radius equal to that distance. It could be anywhere on the circle unless some additional information were available.
If you look back at your original Question, it seemed that you were speaking (about a car) of knowing where the vehicle was at a starting point in time and again at some ending point. You also refer to a constant velocity (and predefined path) which seems to relate to the "constant or a variable velocity on a track" mentioned in your last Clarification.
Let me ask this. Is the aircraft's position known at the "starting point in time"? It seems to me that what you would want to do for an aircraft simulation is to "integrate" its velocity from a known starting point to obtain the aircraft's position at future points in time.
Perhaps what you are coming up against is a difficulty in converting from distance in meters to (change in) degrees of latitude/longitude. Degrees of latitude are a nearly constant length (in meters or kilometers) whereas the "length" of a degree of longitude varies from a maximum at the equator down to zero at the poles. In other words the length of a degree of longitude depends on latitude (but not conversely).
regards, mathtalk-ga
I wanted to find out if we could maybe do things simpler that what we talked about before.....We talked about having 3 sets of lat/long, upper right, lower left, and center. Would it be simple if all we had was the center lat/long, and if I knew the aircraft was for ex. say 1100 meters west, and 700 meters north of my center lat/long, would I be able to figure out what my new lat/long is? Regds,
arunkk
Below is what I consider a valuable but somewhat independent portion of the solution to your problem. It presents formulas for determining the lengths of degrees of latitude and longitude as these vary with latitude. It also provides an opportunity to review a bit of the relations between angles measured in radians and angles measured in degrees.
I'm posting this first as an extended Comment so that I can best focus the Answer on how to use the resulting values (for lengths of degrees) to solve your problem.
Let lat = angle of latitude in radians. These two functions give the lengths in meters of a degree of latitude and a degree of longitude, respectively, at that latitude:
latlen = m1 + m2*cos(2*lat) + m3*cos(4*lat) + m4*cos(6*lat)
m1 = 111132.92
m2 = -559.82
m3 = 1.175
m4 = -0.0023
longlen = p1*cos(lat) + p2*cos(3*lat) + p3*cos(5*lat)
p1 = 111412.84
p2 = -93.5
p3 = 0.118
Note that the first function involves cosines of only even multiples of lat, while the second has only odd multiples. This is consistent with the vanishing of longlen at lat = pi/2 (90 degrees), i.e. at either pole. Since cosine is an even function, we do not need to distinguish here between Northern and Southern latitudes by the sign of lat, but later on we will need the convention that Northern latitudes correspond to positive values of lat and Southern latitudes to negative values.
Let's do a couple of examples to illustrate the use of these formulas, with special attention to the difference between representing angles in degrees and in radians. These formulas are unusual in that the input lat is measured in radians, but there's an implicit reference to degrees in the output (since it is meters per degree).
Most languages are now designed to take radians as the arguments to trigonometric functions like sine and cosine, or to produce radians as the output from inverse trigonometric functions like arctangent. The graphics language you are working with facilitates both radians and degrees by giving 1) functions to convert between them, and 2) versions of the trigonometric functions that use degrees, e.g. cosd( ) and sind( ). I'll try to straddle the issue in the discussion here by giving both the degrees and radians for the particular input angles we treat.
One final refresher: a degree is 60 minutes, and a minute is 60 seconds. Your display for the position will probably convert fractional degrees into minutes and seconds of longitude/latitude.
As a reference check here's a page that gives selected lengths of degrees of longitude as well as the extremes of the lengths for degrees of latitude:
http://www.hypernews.org/HyperNews/get/trails/SAR/291/1.html?nogifs
The extremes cited for length of degrees of latitude are at the equator (minimum) and at the poles (maximum):
at equator: degree of latitude = 68.70 statute miles
= 110561.9321 meters
at a pole: degree of latitude = 69.41 statute miles
= 111704.5663 meters
The formula above for latlen gives respectively 110574.2727 meters at the equator (where lat = 0 radians or degrees) and 111693.9173 meters at the poles (where lat = pi/2 radians or 90 degrees):
at equator: 111132.92 - 559.82 + 1.175 - 0.0023
at a pole: 111132.92 + 559.82 + 1.175 + 0.0023
bearing in mind cos(0) = 1, cos(pi) = -1 and so on.
The discrepancies here are roughly 0.01% and comparable to the relative error in the four digit value in statute miles with which we are benchmarking the formulas.
Note that by design a nautical mile is essentially one minute of latitude, ie. 60 nautical miles per degree of latitude.
At any rate the degrees of latitude are the easy case, because they vary in length so little from one extreme to the other. Let's move on to the lengths of degrees of longitude at varying latitudes. The reference above says that a degree of longitude at 30 degrees North is 59.96 statute miles, or 96496.2656 meters.
If we take latitude 30 degrees North or South, then lat = pi/6. So there:
longlen = 111412.84 cos(pi/6) - 93.5 cos(pi/2) + 0.118 cos(5pi/6)
But if you remember these special angles in trigonometry:
cos(pi/2) = 0
cos(pi/6) = - cos(5pi/6) = SQRT(3)/2
then we get longlen = 96486.2476 meters (again a 0.01% size error).
Finally let's do the length of a degree of longitude at 45 degrees North latitude. The reference above says 49.00 statute miles, or 78857.8555 meters.
Since 45 degrees latitude is lat = pi/4 in radians, and since:
cos(pi/4) = - cos(3pi/4) = - cos(5pi/4) = SQRT(2)/2
we get:
longlen = (111412.84 + 93.5 - 0.118) * SQRT(2)/2
= 78846.8057 meters
and once more the relative error seems to accord with the four digit precision of our reference values.
A more comprehensize tabulation of lengths is given in this PDF document:
http://pollux.nss.nima.mil/NAV_PUBS/APN/Tables/T-07.pdf
Latitude Meters/Deg. of Latitude Meters/Deg. of Longitude
-------- ----------------------- ------------------------
0 110574 111319
30 110852 96486
45 111132 78847
90 111694 0
The agreement between these values and those given by the formulas may appear remarkable, but actually they are both from the same site. I would guess the formulas were used to generate the table linked above. The cited formulas appear beneath the surface of this calculator form:
http://pollux.nss.nima.mil/calc/degree.html
written in JavaScript.
regards, mathtalk-ga
Answers:
>>Will the flight paths be limited to the continental US?
No, our system is being delivered to our customer in Australia, and our terrain model that we are working on is actually a model of the Aust. Outback.... Here I am just using an example lat/long(Dayton,OH), but since the lat/long(s) will be user configurable, I am assuming that our customers will change it to a location closer to home, when they get the system...
>>are there limitations on how far from the "origin" a flight can go?
Our terrain model has a radius of 50Km from the center of the terrain, and the users will be trained to plot the aircraft tracks within range(Technically they could plot points farther than 50km, but they will have no reference to the terrain, since our model will not extend farther than this, but this should not be an issue)....
Thanks
arunkk
The known data are as follows:
1. Upper Right corner latitude/longitude
2. Lower Left corner latitude/longitude
3. Center point latitude/longitude
4. Altitude of aircraft anywhere on the terrain
5. Speed of aircraft in meters/second
6. Distance of aircraft from center point of terrain
The latitude/longitude of all points listed above are fixed(set in a configuration file).....Yes I do want to know the location of the aircraft in terms of Lat/Long at any place in our "box"(terrain)(with minutes/seconds in there for precision) given the known data listed above..am I asking for too much :-) ??
I didn't understand why altitude of the aircraft would come into play, no matter what altitude the aircraft is located, that dosen't affect the location in terms of lat/long does it?
Now regarding velocity, I'm not sure if it makes any difference knowing this for our problem, but yes, our aircraft will fly a constant or a variable velocity on a track which is on the terrain, and we know the the begin time and end time of the track which the aircraft will fly on....
So, I guess what I am looking for is to find teh location of the aircraft using "triangualtion" or someother method, using any/all the data listed above....
Thanks,
A
#If you have any other info about this subject , Please add it free.# |