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 <pi/2, i.e those
that extend around less than one quarter of the circumference of the
earth in longitude. A completely general, but more complicated
algorithm is necessary if greater distances are allowed:

     lat =asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
     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));

---

Request for Question Clarification by mathtalk-ga on 19 May 2004 18:55 PDT

Before we go too far down the path of analyzing that formula, let's
settle the question of whether you are already maintaining the
location of the plane in X,Y,Z coordinates.

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

---

Clarification of Question by arunkk-ga on 19 May 2004 19:32 PDT

Yes, I will always be able to get the xyz location of the aircraft,
that functionality will always remain there....

---

Request for Question Clarification by mathtalk-ga on 20 May 2004 06:58 PDT

Okay, the formula you found apparently is intended to work on a "unit"
sphere and with angles measured in radians.

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

---

Request for Question Clarification by mathtalk-ga on 20 May 2004 18:52 PDT

Hi, arunkk-ga:

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

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