File Exchange

image thumbnail

Geodetic Toolbox

version 2.99 (44.5 KB) by

Toolbox for angle, coordinate and date conversions and transformations. Version 2.99.

25 Ratings



View License

A collection of geodetic functions that solve a variety of problems in geodesy. Supports a wide range of common and user-defined reference ellipsoids. Most functions are vectorized. Most recent version can be found at <>. Functions include:
Angle Conversions
deg2rad - Degrees to radians
dms2deg - Degrees,minutes,seconds to degrees
dms2rad - Degrees,minutes,seconds to radians
rad2deg - Radians to degrees
rad2dms - Radians to degrees,minutes,seconds
rad2sec - Radians to seconds
sec2rad - Seconds to radians
Coordinate Conversions
ell2utm - Ellipsoidal (lat,long) to UTM (N,E) coordinates
ell2xyz - Ellipsoidal (lat,long) to Cartesian (x,y,z) coodinates
sph2xyz - Shperical (az,va,dist) to Cartesian (x,y,z) coordinates
xyz2sph - Cartesian (x,y,z) to spherical (az,va,dist) coordinates
xyz2ell - Cartesian (x,y,z) to ellipsoidal (lat,long,ht) coordinates
xyz2ell2 - xyz2ell with Bowring height formula
xyz2ell3 - xyz2ell using complete Bowring version
utm2ell - UTM (N,E) to ellipsoidal (lat,long) coordinates
Coordinate Transformations
refell - Reference ellipsoid definition
ellradii - Various radii of curvature
ct2lg - Conventional terrestrial (ECEF) to local geodetic (NEU)
dg2lg - Differences in Geodetic (lat,lon) to local geodetic (NEU)
cct2clg - Conventional terrestrial to local geodetic cov. matrix
clg2cct - Local geodetic to conventional terrestrial cov. matrix
rotct2lg - Rotation matrix for conventional terrestrial to local geod.
rotlg2ct - Rotation matrix for local geod. to conventional terrestrial
lg2ct - Local geodetic (NEU) to conventional terrestrial (ECEF)
lg2dg - Local geodetic (NEU) to differences in geodetic (lat,lon)
direct - Direct geodetic problem (X1,Y1,Z1 + Az,VA,Dist to X2,Y2,Z2)
inverse - Inverse geodetic problem (X1,Y1,Z1 + X2,Y2,Z2 to Az,VA,Dist)
simil - Similarity transformation (translation,rotation,scale change)
Date Conversions
cal2jd - Calendar date to Julian date
dates - Converts between different date formats
doy2jd - Year and day of year to Julian date
gps2jd - GPS week & seconds of week to Julian date
jd2cal - Julian date to calenar date
jd2dow - Julian date to day of week
jd2doy - Julian date to year & day of year
jd2gps - Julian date to GPS week & seconds of week
jd2mjd - Julian date to Modified Julian date
jd2yr - Julian date to year & decimal year
mjd2jd - Modified Julian date to Julian date
yr2jd - Year & decimal year to Julian date

Error Ellipses
errell2 - Computes error ellipse semi-axes and azimuth
errell3 - Computes error ellipsoid semi-axes, azimuths, inclinations
plterrel - Plots error ellipse for covariance matrix

cart2euler- Converts Cartesian coordinate rotations to Euler pole rotation
euler2cart- Converts Euler pole rotation to Cartesian coordinate rotations
findfixed - Finds fixed station based on 3D covariance matrix
pltnet - Plots network of points with labels

Example Scripts

DirInv - Simple partial GUI script for direct and inverse problems
DirProb - Example of direct problem
Dist3D - Example to compute incremental 3D distances between points.
InvProb - Example of inverse problem
PltNetEl - Example plot of network error ellipses
ToUTM - Example of conversion from latitude,longitude to UTM

Comments and Ratings (58)



Ankit (view profile)

Hello Mike,

I have a question regarding the formulas that you have used in lg2dg and dg2lg functions. Can you provide me the reference for the formulas of v and r.

Also one more question, is the value for h in both the above mentioned functions equal to the longitude value (origin) in radians or something different?

Finally thanks a lot for sharing this toolbox. It helped me a lot. I am looking forward to hear back from you.


Mike Craymer

Mike Craymer (view profile)

Dear Denis,
Please see my comment dated 27 Jul 2013 below where I reported the correction to the error in ell2utm. That comment also reports a correction to an error in utm2ell.

I have been meaning to upload a new version of the toolbox with the corrected utm2ell but, alas, never seem to find the time. Since my comment about the utm2ell error is now 3 years old and deeply buried amongst other comments, I have just posted the latest version 2.99 of my toolbox today. Sorry for taking so long to post it here.

Note that, as explained in the File Information notes, the latest version of the Geodetic Toolbox can always be found at

Thanks for the toolbox.
I've found that function utm2ell has wrong name inside (ell2utm) and also same typo in description

Mike Craymer

Mike Craymer (view profile)

Hi Amorim,
Sorry for the late reply. Been rather busy lately.

You can do what you want but you need to know the transformation parameters from the original system to the new one. Given the lat,lon of a point in the original system and an azimuth emanating from it, you can compute the azimuth in the new system as follows:

1) Solve the direct geodetic problem in the original system to compute the position of a second point (p2) an arbitrary distance away (say 1000 m) from the original point (p1). You can use my direct.m function for this.

2) Transform both the p1 & p2 points from the old system to the new system. If the transformation is a 7 parameter similarity (aka Helmert) transformation, you can use the latest version of my simil.m function that uses the geocentric Cartesian (CT) coordinate system. That version is not yet in the File Exchange but you can find it on my web site at

Note that you need to first convert the lat,lon of p1 & p2 to geocentric Cartesian coordinates to use simil.m. Use my ell2xyz.m for this conversion. The output transformed Cartesian coordinates of both points in the new system can then be converted to lat,lon using my xyz2ell.m.

3) With lat,lon of p1 & p2 in the new system, solve the inverse geodetic problem to get the azimuth and distance from p1 to p2. You can use my inverse.m function for this. The azimuth from inverse.m will be the azimuth in the new system you are looking for.

Hi, Craymer.
This is a fantastic toolbox you are sharing with us.

I don't know, however, if it can help me with the following problem:

1) I have a geo-located point (lat-long) and a path starting from this point to a particular given direction(bearing - measured from North Pole). How could I possibly translate this geo-direction into a direction in other coordinate system?

Rob Whitfield

I needed some conversions and this toolbox was exactly what I needed. One confusing thing was NEU (North-East-Up)coordinate system. I usually use NED (North-East-Down) and I have seen other use ENU (East-North-Up). But it is easy enough to flip the sign.

Mike Craymer

Mike Craymer (view profile)

Hi Jane,

That is correct. You can assign the output north (dg2lg's dx) and east (dg2lg's dy) to any variables to wish. Just make sure your y,x are not map projection coordinates. Topocentric Cartesian north and east are NOT the same as map projection northing and easting. If you want UTM map projection coordinates, use my ell2utm function.

You can, of course, define your local topocentric Cartesian system anyway you wish. However, the more common convention is to use x for north and y for east (left-handed system), while map projections use y for north and x for east (right-handed system). Thus the warning about misinterpreting the output from dg2lg as map projection coordinates.

Feel free to contact me directly at if you want to discuss this further.


Jane (view profile)

Dear Mike,

Thank you for your reply and detailed explanations.
If I understood correctly, in a case where I want x-axis pointing East, y-axis pointing North, then I can still use your function dg2lg, but I need to assign the output as [y,x]. Am I right?


Mike Craymer

Mike Craymer (view profile)

Dear Jane,

The output of dg2lg is correct. The output dx,dy are in the local geodetic (LG) coordinate system centered at the lat,lon you specific in the input for dg2lg. The local geodetic coordinate system is defined by dg2lg, following the convention of Vanicek & Krakiwsky (Geodesy: The Concepts, 1986), as a left-handed Cartesian coordinate system with the x axis pointing towards north (N), the y axis toward east (E) and the z axis up. This is defined in the help message for dg2lg.

In your example, dlon is larger than the dlat so that dy (E) will be larger than dx (N) as shown in the output from dg2lg. It appears the Woods Hole Institution's NDSF Utility is treating the dx as east and dy as north. That is the convention used for map projections like UTM, which the local geodetic system is not.

In a future version of my Geodetic Toolbox I will be changing the notation for the local geodetic system from dx,dy to dn,de to avoid the confusion with axes definition.

I hope this explains the dg2lg output for you. Don't hesitate to contact me if you have any further questions.


Jane (view profile)

Hi Mike,

Thanks a lot for sharing this file. I was using the function [dx,dy]=dg2lg(dlat,dlon,lat,lon). But the dx, dy results I got seems to be the dy, dx results I got from the website
For example:
lat = 51.945086*pi/180;
lon = 4.039216*pi/180;
dlat = 51.947022*pi/180 - lat;
dlon = 4.054263*pi/180 - lon;
dx =
dy =
But the resutls from the above website are: dx = 1.0347e+003, dy = 215.4116.

May I know the possible reason for this?


Val Schmidt

Val Schmidt (view profile)

OMG. Mike, you are totally correct. I was moving too quickly. How embarrassing. Thanks. -Val

Mike Craymer

Mike Craymer (view profile)

Contrary to what you claim, the results from Palacios's deg2utm are indeed identical with my ell2utm function. You have apparently misinterpreted the output from deg2utm and ell2utm. In my ell2utm/utm2ell functions, n=Northing and e=Easting. These are explicitly defined in the help comments. In the notation of Palacios's deg2utm/utm2deg functions and many map projection formulae, x=Easting (what you call "a") and y=Northing (what you call "b"). Unfortunately, Palacios does not explicitly define what x & y are which may explain your misinterpretation. In the example you give, my ell2utm's Northing (n) and Easting (e) are identical with deg2utm's Northing (y, your b) and Easting (x, your a). Thus, ell2utm and deg2utm give identical results! I would therefore appreciate if you would reconsider your 3-star rating of my toolbox. Thank you.

Val Schmidt

Val Schmidt (view profile)

I am comparing this code with deg2utm and utm2deg from Rafael Palacios available elsewhere in MATLAB central. I've been using these other functions for a long time, with other software and believe them to provide correct answers for conversion to WGS84 based UTM coordinates. However i don't get the same answers here and I'm not sure if I'm doing something wrong or it is a bug. The math in the implementations is sufficiently different that it's not easy for me to decipher. (This is not my science). Here's what I mean:

[a b c] = deg2utm(43,-70)
a =
b =
c =
19 T

Compared with:

>> [a b e2 finv] = refell('WGS84')
a =
b =
e2 =
finv =
>> [n e z] = ell2utm(43*pi/180,-70*pi/180,a,e2)
n =
e =
z =

This zone is correct, but the other values are vastly different. Any ideas what is amiss?



Filip (view profile)

Very useful toolbox.

Geodetic network (1,2,3 D) adjustment toolbox would also be significant.


Filip (view profile)

Mike Craymer

Mike Craymer (view profile)

Unless otherwise stated in the help messages, you cannot use files of data as input to my toolbox functions. You must first read the data into Matlab variables and then use the variables as input to the functions.

In the example you give, if n.txt, e.txt and u.txt are text files containing local geodetic north, east and up coordinates, respectively, try using the following:

lat=0.76; % radians
lon=0.36; % radians

Feel free to email me at if you need further help using my toolbox.


>> [dx,dy,dz]=lg2ct('n.txt','e.txt','u.txt',0.76,0.36)
Error using .*
Matrix dimensions must agree.

Error in lg2ct (line 46)
dX=sum(RR'.*[dx dy dz],2);

Mike Craymer

Mike Craymer (view profile)

Please see my comment dated 27 Jul 2013 below where I reported the correction to the error in ell2utm. That comment also reports a correction to an error in utm2ell.

Before reporting an error, please have a look at my comments for possible corrections. I was planning to post an update to the toolbox this summer with these and other fixes but, alas, have not been able to find the time. Hopefully in the next few weeks. I apologize for the delay.


In ell2utm.m, should
be changed to:

I got an error as follows:
>> ell2utm(lon,lat)
Error using *
Inner matrix dimensions must agree.
Error in ell2utm (line 97)


In ell2utm.m, should
be changed to:

I got an error as follows:
>> ell2utm(lon,lat)
Error using *
Inner matrix dimensions must agree.
Error in ell2utm (line 97)


cai (view profile)

"Geodetic problems" are about Geodesics on an ellipsoid, not straight line.
So your "direct" and "inverse" functions seems not working on "Geodetic problems".

Mike Craymer

Mike Craymer (view profile)

Many thanks to Kyle for reporting the error in utm2ell for points in the southern hemisphere. The function will be fixed in the next release following his suggestion to use negative zone values for such points. For now users should subtract 1e7 m from southern hemisphere northings.


Kyle (view profile)

Great work Mike.

Small problem with utm2ell I think though; it doesn't work for the southern hemisphere.

Specifically, this line does not modify the false northing for the southern hemisphere:


I would suggest perhaps using a signed Zone to denote southern hemisphere and then:


Mike Craymer

Mike Craymer (view profile)

Another error was discovered in the ell2utm function. The test for UTM zones less than zero should be a test for zones less than OR EQUAL TO zero. Replace




The error occurs only for zone 60 (longitudes 174 - <180 east).

Thanks to Mohammad Ali Goudarzi for pointing out the error. I will post a new version of the toolbox with this correction and the ones given in my 27 Jul 2013 comment as soon as possible.

Mike Craymer

Mike Craymer (view profile)

Dear Dmitry,
Sorry I didn't see your post sooner. Here is an example of converting geocentric Cartesian coordinates to ellipsoidal with xyz2ell3 and then back again with ell2xyz:

>> [X,Y,Z]=ell2xyz(deg2rad(45),deg2rad(-79),300);
>> [lat3,lon3,h3]=xyz2ell3(X,Y,Z);
>> [X3,Y3,Z3]=ell2xyz(lat3,lon3,h3);
>> [X3-X;Y3-Y;Z3-Z]

ans =

1.0e-06 *


As you can see, the differences are less than a micron.


Dmitry (view profile)

Hi, thanks for the code!
I'm using the toolbox to compute movement across a custom size relatively flat ellipsoid (flattening = .8 for example). To get me a handle on the coordinate transformation functions, can someone please show an example of a surface point's cartesian coordinates being converted with xyz2ell3 and than back with ell2xyz. I cannot seem to arrive to a matching result. Thanks!

Fei Liu

Mike Craymer

Mike Craymer (view profile)

Two errors were discovered in the ell2utm.m and utm2ell.m functions. In ell2utm.m there is a vectorized calculation error for variable E2. Replace




Thanks to John Marcovici for reporting this error.

And in utm2ell.m the function name on lines 1 & 2 is incorrect. Replace

function [lat,lon]=ell2utm(N,E,Zone,a,e2,lcm)
% ELL2UTM Converts UTM coordinates to ellipsoidal coordinates.


function [lat,lon]=utm2ell(N,E,Zone,a,e2,lcm)
% UTM2ELL Converts UTM coordinates to ellipsoidal coordinates.

Thanks to Andreas Wuestefeld for pointing out this error.


wg (view profile)

really amazing!!!


Peng (view profile)


Pavan (view profile)

Helped a lot, Thanks.

Mike Craymer

Mike Craymer (view profile)

Re: 23 Jul 2011 post by muhammad faiz pa'suya

Dear Muhammad: The ell2utm function will automatically determine and output the standard UTM zone in which your input coordinates fall. To also have it output the central meridian for the zone(s), change the first line of the ell2utm.m function from

function [N,E,Zone]=ell2utm(lat,lon,a,e2,lcm)
function [N,E,Zone,lcm]=ell2utm(lat,lon,a,e2,lcm)

This will be implemented in the next version of the Toolbox. To understand how the zones are determined, see the Wikipedia entry for UTM.

Very useful! Thank you very much.

joo tan

if i wnat to set the central meridian, like zon 50, where can i get the central meridian value??

Vihang bhatt

It is really a good toolbox. Thank you for making my life little easy. One suggestion for the author on Julian dates. In the function jd2cal, jd has to be positive. jd can be negitive (if they exist), following modification needed to the code

dy = c - e - fix(30.6001*f) + rem((jd+0.5),max(a,1));
dy = c - e - fix(30.6001*f) + rem((jd+0.5),a);

In above case you are able to get 1st gragorian date for zeroth julian day. otherwise greogrian calander start from 2nd jan.

Dr. Vihang Bhatt

Mike Craymer

Mike Craymer (view profile)

Sorry again! I keep forgetting that the MATLAB File Exchange doesn't like the use of the standard angle brackets enclosing URLs. Here is the clickable URL sans brackets:

Mike Craymer

Mike Craymer (view profile)

A new version 2.95 of the Geodetic Toolbox is now available. Unfortunately, I am unable upload it to the MATLAB Central File Exchange (keep getting an error). Until the Mathworks resolves the problem, you can find the new version at <>.

Updates include:

- Added new jd2mjd & mjd2jd functions for modified Julian date conversions.
- Modified ct2lg & lg2ct functions to optionally use different lat,lon for each point.
- Corrected use of ell2utm function in ToUTM example script.
- Removed "clear all" in example scripts to avoid clearing user's workspace.
- Modified functions to use GRS80 reference ellipsoid by default.

See Content.m for the full list of changes.

Mike Craymer

Mike Craymer (view profile)

Sorry the URL's in my previous comment did not format correctly. They should have been specified as:

Mike Craymer

Mike Craymer (view profile)

Dear Ram,
By default, the ell2utm function uses the standard UTM zone definition where the earth is divided into 60 zones each 6 deg of longitude in width. Zone 1 is bounded by longtiudes 180 deg E and 186 deg E.


By this definition, Zone 44 is bounded by longitudes 78 deg E and 84 deg E, while Zone 45 is bounded by 84 deg E and 90 deg E. That is, Zone 44 starts at 180+(44-1)*6-360=78. The boundary between Zones 44 and 45 therefore bisects what you call Zone 45R. You can verify this with the on-line version of GeoConvert at


In any case, the ell2utm function allows you to specify the central meridian for any non-standard zone definitions. See help ell2utm for more information.


Mike Craymer

Mike Craymer (view profile)

Dear Bryce,
You are right! The "clear all" in dates.m is not cool. I've replaced it with clearing the specific variables used in the script. A new version 2.95 of the toolbox will be posted shortly fixing this in dates.m as well as other affected example scripts. In the meantime, users should remove any "clear" or "clear all" when using the examples. Thank you for bringing this to my attention!


Ist (view profile)

That's seems to be very useful package. Thank You!

Ram Acharya

It is a good tool. However, I couldn't make its use while I wanted to convert lat longs to UTM, for lats [26.4546 -- 30.4485 degrees North ] and longs [80.074 -- 88.23319 degrees East]. The UTM zone is 45R . However your tool splits it into 44R and 45R. Could you review your code for that particular region. Thanks.


Bryce (view profile)

dates.m does a 'clear all' at the beginning of its loop. Not cool!

It would be much better to clear the actual names of variables that you use in the script. Resetting people's workspace variables is not nice.

Looks like a good toolbox, though. Thanks!

Mike Craymer

Mike Craymer (view profile)

Dear Jonathon,

I just saw your question about transforming lat,lon to N,E,U. The ct2lg function in your last step requires as input the X,Y,Z coordinate *differences* between the two points. In your example, you entered the X,Y,Z coordinates for just one point. ct2lg would have interpreted this as very large X,Y,Z coordinate differences. The correct conversion for your example is given below (you need to enter the X,Y,Z differences in ct2lg as Xec-Xec, Yec-Yec, Zec-Zec).

Thanks for your comments!

>> [a,b,e2,finv] = refell('WGS84'); %get ellipsoid params
rlat = deg2rad(40); rlon = deg2rad(-108); %lat,lon
[Xec Yec Zec] = ell2xyz(rlat,rlon,0,a,e2) %convert to ECEF xyz
[N E Up] = ct2lg(Xec-Xec,Yec-Yec,Zec-Zec,rlat,rlon) %convert to local NEU

Xec =


Yec =


Zec =


N =


E =


Up =




Thank you for such a useful toolbox! I have a question, however, regarding transforming lat,lon on the WGS84 ellipsoid to local North East Up. If I use the same lat,lon coordinate as both my point to convert and my origin, why would I get a -21.5 km local North value? Shouldn't North and East both be zero?

Thanks again,


>> [a,b,e2,finv] = refell('WGS84'); %get ellipsoid params
rlat = deg2rad(40); rlon = deg2rad(-108); %lat,lon
[Xec Yec Zec] = ell2xyz(rlat,rlon,0,a,e2) %convert to ECEF xyz
[N E Up] = ct2lg(Xec,Yec,Zec,rlat,rlon) %convert to local NEU

Xec =
Yec =
Zec =

N =
E =
Up =



Thanks for that, very useful

Mike Craymer

Mike Craymer (view profile)

I corrected the bug for vector and array input to function ell2utm per Sebastian Holz's comments and posted a new version 2.91. Unfortunately, the fix only worked for row vectors. I've corrected it again in version 2.92 and tested it this time to make sure it works. Sorry for any problems this may have caused. In addition to error checking, I'll consider adding array input to all functions in the next major release (this Summer I hope).

Sebastian Hölz

There is a potential bug in function ell2UTM, which may lead to wrong results in the calculated northing, if the funciton is called with a vector containing coordinates from both southern and northern hemisphere. Change lines 23-27, which read ...

if lat>=0

to ...

No(size(lat))=0; % False northing (north)
No(lat<0) = 1e7; % False northing (south)



under matlab which file do i put this in so that it is being used?

jaime torres


Gene Newton

Thank you.

Ray Borough

Very Useful

Jagkrich A.warangkul


Ali Ebrahimi

Nice Work

Nice work

John D'Errico

This seems pretty good from what I checked. There are many conversions in here.

A couple of minor points. I notice that there is no error checking. For example, in ellradii one must provide an axis length and eccentricity (squared). But there are no checks on the proper number of parameters or even on the sign of the eccentricity.

In dms2deg, I noticed one interesting feature. Converting from 32 degrees, 12 minutes, -3 seconds, results in a degree prediction of:

dms2deg([32 12 -3])
ans =

Overall, its still pretty good.





Corrected function name & test for points in southern hemisphere in utm2ell; Corrected E2 computation, improved zone computation & corrected for zero Zones in ell2utm; Added transformations for both left-handed LG & right-handed CT systems in simil.


Added utm2ell, cart2euler & euler2cart; corrected cal2jd, ell2utm, xyz2ell; modified cct2clg & clg2cct; vectorized jd2yr; corrected help comments in lg2ct, pltnet. See individual functions for details.






Added jd2mjd & mjd2jd for modified Julian date conversions. Modified ct2lg & lg2ct for different lat,lon for each point. Corrected ToUTM. Removed clear all in example scripts. Modified functions to use GRS80 reference ellipsoid by default.


Added Matlab File Exchange BSD licensing. No changes to code since v2.92.


Added Matlab File Exchange BSD licensing. No changes to code since v2.92.


Corrected correction to ell2utm function in v2.91 (and tested it this time!).


Corrected ell2utm function for mixed north and south latitudes. Thanks to Sebastian Holz for pointing out the error and providing a fix.

MATLAB Release
MATLAB 8.1 (R2013a)

Download apps, toolboxes, and other File Exchange content using Add-On Explorer in MATLAB.

» Watch video