Bug #729

psmeca: newX and newY does not work in cartesian time axes

Added by Dongdong almost 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:2015-07-27
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:all Platform:

Description

I am trying to plot beach balls on a non-geographic basemap. The X axes is time, Y axes is moment magnitude.

The code below is a simple example which works:

#!/bin/bash
J=-JX25c/15c
R=-R2015-07-03T00:00/2015-07-25T00:00/2/7

gmt psmeca $J $R -Sa2 -C -Gred -W0.3p -N -Bxa1d+l"Time" -Bya1"Mw" -BWSen << EOF > test.ps
2015-07-08T09:07 4.5  10  125  30  90  4.5
EOF

Then I add 'newX' and 'newY' to the input data to shift the beach ball. The new code fails:

#!/bin/bash
J=-JX25c/15c
R=-R2015-07-03T00:00/2015-07-25T00:00/2/7

gmt psmeca $J $R -Sa2 -C -Gred -W0.3p -N -Bxa1d+l"Time" -Bya1"Mw" -BWSen << EOF > test.ps
2015-07-08T09:07 4.5  10  125  30  90  4.5 2015-07-06T09:07  5.5
EOF

The bug is caused by an incorrect decode of newX and newY.

In the source code of 'psmeca.c', the newX and newY are converted to float using function 'atof':

# line 735
xynew[ix] = atof (col[last-1+new_fmt]);                              
xynew[iy] = atof (col[last+new_fmt]);

It fails at least in two cases:
1. newX or newY is time;
2. newX/newY is latitude/longitude in 'ddd:mm:ss' format.

One way to fix this bug may be using 'GMT_scanf' to decode newX and newY:

GMT_scanf (GMT, col[last-1+new_fmt], GMT->current.io.col_type[GMT_IN][GMT_X], &xynew[ix]);
GMT_scanf (GMT, col[last+new_fmt],   GMT->current.io.col_type[GMT_IN][GMT_Y], &xynew[iy]);

BTW, in GMT4, both X/Y and newX/newY are coverted to float using 'atof'.

Associated revisions

Revision 14640
Added by Paul almost 2 years ago

Address issue #729

History

#1 Updated by Paul almost 2 years ago

  • Status changed from New to Resolved
  • Assignee set to Paul
  • % Done changed from 0 to 100

Thanks, I have applied that fix. In r14641.

#2 Updated by Dongdong almost 2 years ago

The same bug exists in GMT4. Will it be fixed?

#3 Updated by Paul almost 2 years ago

Fixed in r10319.

#4 Updated by Remko almost 2 years ago

  • Status changed from Resolved to Closed

Closed by verification

Also available in: Atom PDF