GEOD(1)

πŸ’… GEOD(1) β€” PROJ, section 1, and yes she's that girl πŸ’…

okay so before we even start: this one lives in the PROJ manual, section 1, and it's called geod. she does great-circle math and she does it flawlessly. let's get into it bestie 🫢


✨ NAME ✨

geod β€” geodesic computations ✨ that's the whole pitch, no notes.


πŸ¦‹ SYNOPSIS πŸ¦‹

geod +ellps=<ellispoid> [-afFIlptwW [args]] [+opt[=arg] ...] file ...

invgeod +ellps=<ellispoid> [-afFIlptwW [args]] [+opt[=arg] ...] file ...

(yes <ellispoid> is spelled like that in the original, we don't fix, we respect πŸ’…)


πŸ’– DESCRIPTION πŸ’–

So there's two of them, right: geod (the direct one) and invgeod (the inverse one), and they both do geodesic (Great Circle) computations, just from different directions πŸ‘‘

  • direct β†’ you give her an initial point's latitude, longitude, azimuth and distance, and she hands you back the latitude, longitude and back azimuth of the terminus point.
  • inverse β†’ you give her the latitudes and longitudes of an initial and a terminus point, and she gives you the forward and back azimuths plus the distance between them.

The results are accurate to round off for |f| < 1/50, where f is flattening. no cap, that's the guarantee πŸ”₯

Heads up: invgeod may not be available on all platforms. If yours is being flaky, just use geod -I instead πŸ’€

The following command-line options can appear in any order (she's flexible like that ✨):

  • -I β€” says "do the inverse geodesic computation pls". You can use this with geod as an alternative to running invgeod.
  • -a β€” outputs the latitudes and longitudes of the initial and terminal points, the forward and back azimuths, and the distance. everything, bestie, the full fit 🌈
  • -t<a> β€” where a is a character you pick to be the first character that marks a control line, which then gets passed straight through without processing.
  • -le β€” gives you a listing of all the ellipsoids you can select with the +ellps= option. window shopping πŸ›οΈ
  • -lu β€” gives you a listing of all the units you can select with the +units= option. (Default units are meters.)
  • -f <format> β€” where format is a printf format string controlling the output form of the geographic coordinate and azimuth values. The default mode is DMS.
  • -F <format> β€” where format is a printf format string controlling the output form of the distance value. The default mode is "%.3f".
  • -w<n> β€” where n is the number of significant fractional digits to use for seconds output (when the option isn't specified, -w3 is assumed).
  • -W<n> β€” where n is the number of significant fractional digits to use for seconds output. When -W is employed, the fields will be constant width with leading zeroes. so tidy πŸ’…
  • -p β€” makes the azimuthal values output as unsigned DMS numbers between 0 and 360 degrees. also, go look at -f again, she's relevant here πŸ‘€

The +opt command-line options are associated with geodetic parameters for specifying the ellipsoidal or sphere to use, plus controls. These options are processed in left to right order from the command line. If you re-enter an option, that's ignored β€” the first occurrence is assumed to be the desired value. one shot, first answer, no takebacks 🎯

See the PROJ documentation for a full list of these parameters and controls. (iykyk, the docs are the moment πŸ“š)

One or more files (processed in left to right order) specify the source of data to be transformed. A - will specify the location of processing standard input. If no files are specified, the input is assumed to be from stdin. classic 🫢

For direct determinations, input data must be in latitude, longitude, azimuth and distance order, and output will be the latitude, longitude and back azimuth of the terminus point. For inverse mode you input the latitude and longitude of the initial and terminus points, and you get back the respective forward and back azimuth from the initial and terminus points, along with the distance between the points. slay πŸ’–

Input geographic coordinates (latitude and longitude) and azimuthal data must be in decimal degrees or DMS format, and input distance data must be in units consistent with the ellipsoid major axis or sphere radius units. The latitude must lie in the range [-90d,90d] β€” that's a hard limit, fr fr, don't test her.

Output geographic coordinates and azimuths will be in DMS (if the -f switch isn't employed) to 0.001" with trailing, zero-valued minute-second fields deleted. Output distance data will be in the same units as the ellipsoid or sphere radius.

The Earth's ellipsoidal figure may be selected in the same manner as program proj by using +ellps=, +a=, +es=, etc. pick your fighter 🌍

geod may also be used to determine intermediate points along either a geodesic line between two points or along an arc of specified distance from a geographic point. In both cases an initial point must be specified with +lat_1=lat and +lon_1=long parameters, and either a terminus point +lat_2=lat and +lon_2=long, or a distance and azimuth from the initial point with +S=distance and +A=azimuth must be specified.

If points along a geodesic are to be determined, then either +n_S=integer (specifying the number of intermediate points) and/or +del_S=distance (specifying the incremental distance between points) must be specified.

To determine points along an arc equidistant from the initial point, both +del_A=angle and +n_A=integer must be specified, which determine the respective angular increments and number of points to be determined.


πŸŽ€ EXAMPLES πŸŽ€

Okay this first script is iconic β€” it determines the geodesic azimuths and distance in U.S. statute miles from Boston, MA, to Portland, OR:

geod +ellps=clrk66 -I +units=us-mi <<EOF
42d15'N 71d07'W 45d31'N 123d41'W
EOF

which gives the results:

-66d31'50.141" 75d39'13.083" 2587.504

where the first two values are the azimuth from Boston to Portland, the back azimuth from Portland to Boston, followed by the distance. ate πŸ’…

An example of forward geodesic use is to use the Boston location and determine Portland's location by azimuth and distance:

geod +ellps=clrk66 +units=us-mi <<EOF
42d15'N 71d07'W -66d31'50.141" 2587.504
EOF

which gives:

45d31'0.003"N 123d40'59.985"W 75d39'13.094"

i.e., the latitude and longitude of Portland, and the back azimuth from Portland to Boston. round trip, we love a return journey πŸ¦‹

NOTE: Lack of precision in the distance value compromises the precision of the Portland location. 😭 so if your Portland is looking a little off, check your distance, bestie.

🌸 FURTHER READING 🌸

  1. GeographicLib.
  2. C. F. F. Karney, Algorithms for Geodesics, J. Geodesy 87(1), 43–55 (2013); addenda.
  3. A geodesic bibliography.

πŸ’… SEE ALSO πŸ’…

proj(1), cs2cs(1), cct(1), gie(1), projinfo(1), projsync(1) β€” the whole friend group 🫢


πŸ‘‘ BUGS πŸ‘‘

A list of known bugs can be found at ‐ https://github.com/OSGeo/PROJ/issues where new bug reports can be submitted to. go off, file that report πŸ”₯


🌈 HOME PAGE 🌈

https://proj.org/ β€” the mothership ⭐


πŸ’œ AUTHOR πŸ’œ

Charles Karney


1983-2026, PROJ contributors


and that's the tea β˜• this page is version 9.9, dated 15 Sep 2026, and honestly? she ate. mwah πŸ’‹βœ¨πŸŽ€

πŸ“¦ where this page comes from