MAPPROJECT(1gmt) | GMT | MAPPROJECT(1gmt) |
mapproject - Do forward and inverse map transformations, datum conversions and geodesy
mapproject [ tables ] -Jparameters
-Rregion [
-Ab|B|f|F|o|O[lon0/lat0][+v]
] [ -C[dx/dy] ] [ -Dc|i|p ]
[ -E[datum] ] [ -F[unit] ] [
-G[lon0/lat0][+a][+i][+u[+|-]unit][+v]
] [ -I ] [
-Lline.xy[+u[+|-]unit][+p]
] [ -N[a|c|g|m] ] [
-Q[d|e ] [ -S ] [
-T[h]from[/to] ] [ -V[level] ] [
-W[w|h] ] [
-Z[speed][+a][+i][+f][+tepoch]
] [ -bbinary ] [ -dnodata ] [ -eregexp ] [
-fflags ] [ -ggaps ] [ -hheaders ] [ -iflags ] [
-oflags ] [ -pflags ] [ -sflags ] [
-:[i|o] ]
Note: No space is allowed between the option flag and the associated arguments.
mapproject reads (longitude, latitude) positions from tables [or standard input] and computes (x,y) coordinates using the specified map projection and scales. Optionally, it can read (x,y) positions and compute (longitude, latitude) values doing the inverse transformation. This can be used to transform linear (x,y) points obtained by digitizing a map of known projection to geographical coordinates. May also calculate distances along track, to a fixed point, or closest approach to a line. Alternatively, can be used to perform various datum conversions. Additional data fields are permitted after the first 2 columns which must have (longitude,latitude) or (x,y). See option -: on how to read (latitude,longitude) files. Finally, mapproject can compute a variety of auxiliary output data from input coordinates that make up a track. Items like azimuth, distances, distances to other lines, and travel-times along lines can all be computed by using one or more of the options -A, -G, -L, and -Z.
For map distance unit, append unit d for arc degree, m for arc minute, and s for arc second, or e for meter [Default], f for foot, k for km, M for statute mile, n for nautical mile, and u for US survey foot. By default we compute such distances using a spherical approximation with great circles. Prepend - to a distance (or the unit is no distance is given) to perform "Flat Earth" calculations (quicker but less accurate) or prepend + to perform exact geodesic calculations (slower but more accurate).
The ASCII output formats of numerical data are controlled by parameters in your gmt.conf file. Longitude and latitude are formatted according to FORMAT_GEO_OUT, absolute time is under the control of FORMAT_DATE_OUT and FORMAT_CLOCK_OUT, whereas general floating point values are formatted according to FORMAT_FLOAT_OUT. Be aware that the format in effect can lead to loss of precision in ASCII output, which can lead to various problems downstream. If you find the output is not written with enough precision, consider switching to binary output (-bo if available) or specify more decimals using the FORMAT_FLOAT_OUT setting.
To convert UTM coordinates in meters to geographic locations, given a file utm.txt and knowing the UTM zone (and zone or hemisphere), try
gmt mapproject utm.txt -Ju+11/1:1 -C -I -F
To transform a file with (longitude,latitude) into (x,y) positions in cm on a Mercator grid for a given scale of 0.5 cm per degree, run
gmt mapproject lonlatfile -R20/50/12/25 -Jm0.5c > xyfile
To transform several 2-column, binary, double precision files with (latitude,longitude) into (x,y) positions in inch on a Transverse Mercator grid (central longitude 75W) for scale = 1:500000 and suppress those points that would fall outside the map area, run
gmt mapproject tracks.* -R-80/-70/20/40 -Jt-75/1:500000 -: -S -Di -bo -bi2 > tmfile.b
To convert the geodetic coordinates (lon, lat, height) in the file old.dat from the NAD27 CONUS datum (Datum ID 131 which uses the Clarke-1866 ellipsoid) to WGS 84, run
gmt mapproject old.dat -Th131 > new.dat
To compute the closest distance (in km) between each point in the input file quakes.dat and the line segments given in the multisegment ASCII file coastline.xy, run
gmt mapproject quakes.dat -Lcoastline.xy+uk > quake_dist.dat
Given a file with longitude and latitude, compute both incremental and accumulated distance along track, and estimate travel times assuming a fixed speed of 12 knots. We do this with
gmt mapproject track.txt -Gn+a+i -Z12+a --TIME_UNIT=h > elapsed_time.txt
where TIME_UNIT is set to hour so that the speed is measured in nm (set by -G) per hour (set by TIME_UNIT). Elapsed times will be reported in hours (unless +f is added to -Z for ISO elapsed time).
The rectangular input region set with -R will in general be mapped into a non-rectangular grid. Unless -C is set, the leftmost point on this grid has xvalue = 0.0, and the lowermost point will have yvalue = 0.0. Thus, before you digitize a map, run the extreme map coordinates through mapproject using the appropriate scale and see what (x,y) values they are mapped onto. Use these values when setting up for digitizing in order to have the inverse transformation work correctly, or alternatively, use awk to scale and shift the (x,y) values before transforming.
For some projection, a spherical solution may be used despite the user having selected an ellipsoid. This occurs when the users -R setting implies a region that exceeds the domain in which the ellipsoidal series expansions are valid. These are the conditions: (1) Lambert Conformal Conic (-JL)and Albers Equal-Area (-JB) will use the spherical solution when the map scale exceeds 1.0E7. (2) Transverse Mercator (-JT) and UTM (-JU) will will use the spherical solution when either the west or east boundary given in -R is more than 10 degrees from the central meridian, and (3) same for Cassini (-JC) but with a limit of only 4 degrees.
GMT will use ellipsoidal formulae if they are implemented and the user have selected an ellipsoid as the reference shape (see PROJ_ELLIPSOID). The user needs to be aware of a few potential pitfalls: (1) For some projections, such as Transverse Mercator, Albers, and Lambert's conformal conic we use the ellipsoidal expressions when the areas mapped are small, and switch to the spherical expressions (and substituting the appropriate auxiliary latitudes) for larger maps. The ellipsoidal formulae are used as follows: (a) Transverse Mercator: When all points are within 10 degrees of central meridian, (b) Conic projections when longitudinal range is less than 90 degrees, (c) Cassini projection when all points are within 4 degrees of central meridian. (2) When you are trying to match some historical data (e.g., coordinates obtained with a certain projection and a certain reference ellipsoid) you may find that GMT gives results that are slightly different. One likely source of this mismatch is that older calculations often used less significant digits. For instance, Snyder's examples often use the Clarke 1866 ellipsoid (defined by him as having a flattening f = 1/294.98). From f we get the eccentricity squared to be 0.00676862818 (this is what GMT uses), while Snyder rounds off and uses 0.00676866. This difference can give discrepancies of several tens of cm. If you need to reproduce coordinates projected with this slightly different eccentricity, you should specify your own ellipsoid with the same parameters as Clarke 1866, but with f = 1/294.97861076. Also, be aware that older data may be referenced to different datums, and unless you know which datum was used and convert all data to a common datum you may experience mismatches of tens to hundreds of meters. (3) Finally, be aware that PROJ_SCALE_FACTOR have certain default values for some projections so you may have to override the setting in order to match results produced with other settings.
The production order for the geodetic and temporal columns produced by the options -A, -G, -L, and -Z is fixed and follows the alphabetical order of the options. Hence, the order these options appear on the command line is irrelevant. The actual output order can of course be modulated via -o.
gmt, gmt.conf, gmtvector, project
Bomford, G., 1952, Geodesy, Oxford U. Press.
Snyder, J. P., 1987, Map Projections - A Working Manual, U.S. Geological Survey Prof. Paper 1395.
Vanicek, P. and Krakiwsky, E, 1982, Geodesy - The Concepts, North-Holland Publ., ISBN: 0 444 86149 1.
2019, P. Wessel, W. H. F. Smith, R. Scharroo, J. Luis, and F. Wobbe
May 21, 2019 | 5.4.5 |