Bug #1084

default datum in mapproject

Added by Marcelo 7 months ago. Updated 6 months ago.

Status:ClosedStart date:2017-04-26
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next minor release
Affected version:5.x-svn Platform:

Description

from man mapproject:

-E[datum]

Convert from geodetic (lon, lat, height) to Earth Centered Earth Fixed (ECEF) (x,y,z) coordinates (add -I for the inverse conversion). Append datum ID (see -Qd) or give ellipsoid:dx,dy,dz where ellipsoid may be an ellipsoid ID (see -Qe) or given as a[,inv_f], where a is the semi-major axis and inv_f is the inverse flattening (0 if omitted). If datum is - or not given we assume WGS-84.

Then I expected that the following commands will use WGS-84:

echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -E
echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -E-
echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -E --PROJ_ELLIPSOID=WGS-84

These commands result in:
4084427.54424   -4209174.05814  -2497887.63973

which is not what I expected. If I explicitly set WGS-84 in -E option:
echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -E219
echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -EWGS-84:0,0,0
echo "-45:51:42.2560 -23:12:25.6767 605.089" | gmt mapproject -E6378137.000,298.257223563:0,0,0

results what I expected:
4084802.43449   -4209560.39828  -2498056.95956

could be something wrong with the default datum in GMT5?
using 5.4.0_r18031, 5.3.3, 5.3.2, 5.3.1

gmt 4.5.15 and 4.5.14 have the same results, as I expected,
if doing the proper changes:
PROJ_ELLIPSOID ⇒ ELLIPSOID
E219 ⇒ E220

History

#1 Updated by Paul 7 months ago

  • Status changed from New to Resolved
  • Assignee set to Paul
  • Target version set to Candidate for next minor release
  • % Done changed from 0 to 100

A porting bug. In GMT 4 the WGS-84 was the 1st ellipsoid in the list so we hardwired a [0] array index, but in GMT5 we do it by name-lookup and WGS-84 is alphabetically placed. I replaced the hardwired [0] with the obtained index and now the results match. In r18040.

#2 Updated by Joaquim 6 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF