View Question
Q: Linear Interpolation: Need to get LAT/LONG ( Answered,   2 Comments )
 Question
 Subject: Linear Interpolation: Need to get LAT/LONG Category: Science > Math Asked by: arunkk-ga List Price: \$15.00 Posted: 06 May 2004 15:34 PDT Expires: 05 Jun 2004 15:34 PDT Question ID: 342332
 ```Hi, I have a square plane, and I assign the center of the plane, an arbitrary lat/long, and I also do the same for the upper right corner, and the lower left corner..... Let's say I have an object, like a car, that will travel on this plane on a predefined path, at a constant velocity, and I know the start time, and end time, is there any way I can get the Latitude and Longitude of the object at everypoint along the plane using Linear Interpolation(or some other mathematical way). I hope I explained my question well....Any help would be greatly apperciated....Thanks Ex. |========= | (-83 Lat/ 40 Long) | | | | | * | |(-84 Lat/39 Ln)| | | |========= |``` Clarification of Question by arunkk-ga on 06 May 2004 18:20 PDT ```|========= | (-83 Lat/ 40 Long) | | | | | * | |(-84 Lat/39 Ln)| | | |========= | (-85 Lat/38 Long)``` Request for Question Clarification by mathtalk-ga on 07 May 2004 19:22 PDT ```Hi, arunkk-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``` Clarification of Question by arunkk-ga on 07 May 2004 19:45 PDT ```Hi Mathtalk, to clarify your questions......I had my lat/long wrong, it was supposed to be 39Lat/84Long(Dayton, OH, not south pole :-) ) First I want to say that I dont' know much about lat/long, so what I may say may not make sense, but i'll try to be clear.... 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``` Request for Question Clarification by mathtalk-ga on 07 May 2004 19:56 PDT ```Hi, arunkk-ga: 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``` Clarification of Question by arunkk-ga on 07 May 2004 20:58 PDT ```hi mathtalk 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!``` Request for Question Clarification by mathtalk-ga on 08 May 2004 08:41 PDT ```Maybe it would help if you state explicitly what is "known" information and what is to be computed. 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``` Clarification of Question by arunkk-ga on 08 May 2004 10:47 PDT ```Hi, 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``` Request for Question Clarification by mathtalk-ga on 08 May 2004 13:34 PDT ```Sorry, I'm still confused, but I can see we are making progress. 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``` Clarification of Question by arunkk-ga on 08 May 2004 16:31 PDT ```The aircraft can fly a constant velocity on the track, or it can change velocity on the track....(a track is created by the user who literraly uses the mouse to click on the terrain to plot points, and we just draw a line through those points to create the track; the user can leave the velocity at a constant, or change the velocity before plotting another point on the terrain, thus the aircraft can change velocity between points, when I mean points in this context, I don't mean lat/long...I mean an X,Y,Z in world space) 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``` Request for Question Clarification by mathtalk-ga on 09 May 2004 07:40 PDT ```If you knew the XYZ "worldspace" coordinates for the aircraft throughout its flight, would it be sufficient to have a function that provides latitude and longitude from the XYZ coordinates? 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``` Clarification of Question by arunkk-ga on 09 May 2004 08:57 PDT ```If it is possible to get the lat/long of the aircraft from the XYZ Coordinates of the aircraft anywhere on the terrain, that would be great....Yes, the Center Lat/Long in our "box", has the XYZ cordinate of 0,0,0. (Y = North, X = East, and Z = Altitude) Thanks again!``` Request for Question Clarification by mathtalk-ga on 10 May 2004 08:48 PDT ```Hi, arunkk-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``` Clarification of Question by arunkk-ga on 10 May 2004 15:59 PDT ```Hi 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``` Request for Question Clarification by mathtalk-ga on 11 May 2004 18:18 PDT ```Hi, arunkk-ga: 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``` Clarification of Question by arunkk-ga on 11 May 2004 18:34 PDT ```Hi mathtalk 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``` Clarification of Question by arunkk-ga on 18 May 2004 15:27 PDT ```Hi Mathtalk, Just checking in to see if you need any more clarifications?? I hope you have not given up on me :-) Regards, arunkk``` Request for Question Clarification by mathtalk-ga on 18 May 2004 16:31 PDT ```No, but I'm working out how accurate the simplest possible useful formulas are. 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``` Clarification of Question by arunkk-ga on 18 May 2004 16:42 PDT ```Ok, thanks mathtalk....I'll wait for your answer regards arunkk``` Clarification of Question by arunkk-ga on 19 May 2004 12:29 PDT ```mathtalk, 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``` Request for Question Clarification by mathtalk-ga on 19 May 2004 13:03 PDT ```Yes, that's precisely the right idea. 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``` Clarification of Question by arunkk-ga on 19 May 2004 15:28 PDT ```hi mathtalk, 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?``` Request for Question Clarification by mathtalk-ga on 19 May 2004 16:55 PDT ```Hi, arunkk-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``` Clarification of Question by arunkk-ga on 19 May 2004 18:08 PDT ```hi mathtalk, 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
 ```Hi, arunkk-ga: 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. [As already noted, the 100km north-south "diameter" across a flight space of radius 50km is approximate one degree 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: [Maya (MEL) Functions] 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```
 ```If you do not known the errors of the projection of the chart (any chart method), this is that you need: 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).```
 ```Hi, arunkk-ga: 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: [Latitude-Longitude Conversion to Feet] 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: [Length of a Degree of Latitude and Longitude] 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: [Length of a Degree of Latitude and Longitude Computation Home Page] http://pollux.nss.nima.mil/calc/degree.html written in JavaScript. regards, mathtalk-ga```