Feature #911

Using longitudes on y-axis of -JX projection

Added by Michael 11 months ago. Updated 5 months ago.

Status:ResolvedStart date:2016-05-26
Priority:LowDue date:
Assignee:Paul% Done:


Target version:Candidate for next bugfix release


I have a graph with time on x-axis and longitude on y-axis. I use a cartesian projection such as -JX15ct/10cd -R1993-01-01T/2016-06-01T/143.3/146
But I have an error

psxy: Internal Error = GMT_MAP_BAD_LAT_MIN
psxy (GMT_psxy): South is outside -90 to +90

Can you add one more option to specify which geocoordinate used on axis?
Of course, I may use some workaround, --FORMAT_FLOAT_MAP="%.12lg\232 E" (but result is decimal degrees, not arcminutes) or custom labels, so this problem is not critycal.

Associated revisions

Revision 17322
Added by Paul 6 months ago

Finish issue #911


#1 Updated by Joaquim 11 months ago

  • Category set to Invalid

If you want to put the longitudes on Y don't tell the program that it is geographic (the 'd' in 10cd), which is not.

#2 Updated by Michael 11 months ago

Why? The longitude is not a "degrees on x-axis of maps", it is a geographic coordinate and must be printed accordingly with FORMAT_GEO_MAP. And on non-geographic projection it can be on any axis.

#3 Updated by Paul 11 months ago

  • Category deleted (Invalid)
  • Assignee set to Paul

I will have a look if this is an easy thing to accommodate. I suspect it is but will have to trace through how the error arises.

#4 Updated by Paul 11 months ago

  • Status changed from New to In Progress
A few updates on this issue:
  1. You must supply -f0T,1x for GMT to know that your y-input are longitudes. The "d" by itself may indicate degrees but the reasonable assumption would be latitude. With that -f the error message goes away.
  2. I now (r16469) allow for 360-degree periodicity in y if the y-data are flagged as longitude via -f. This means 2000-01-01T, -90 and 2000-01-01T, 270 will be considered the same point.
  3. Axis annotation is not yet working since the Cartesian axis function is not set up to do that. I think this can be modified without too much problems and will look.

#5 Updated by Michael 11 months ago

Thanks for reconsidering this issue.

I forgot that -f option also can specify interpretation of data fields and not check this variant. Can you mention it in documentation of -Jx?

#6 Updated by Paul 6 months ago

  • Status changed from In Progress to Resolved
  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 100

I have fixed this so plotting longitude versus time or whatever works, and added psxy/lon_vs_time.sh test script. It will not annotate the longitudes on the y-axis using dd:mm; this remains a Cartesian number but you do get the degree symbol and it will honor periodicity provided -f is set properly. In r17322.

#7 Updated by Michael 6 months ago

Thanks, it is work as described and also honor FORMAT_GEO_MAP.

Two questions.
If I set -f incorrectly (-f0y,1T instead of -f0x,1T), then script give just degrees on corresponding axis without periodicity and FORMAT_GEO_MAP. It seems, that reporting of error is more logical in this case.

But if I try to honestly get just plain degrees on the axis and use g in -f0g,1T, I get the error:

gmt psxy -R-41/319/1993-01-01T/2016-06-01T -JX15cd/10ct -f0g,1T -By5Y -Bx30 -O -BWSne -Sc0.1i -Ggreen -Wthin xt.txt -Y13c
psxy: Error: Malformed -f argument [0g,1T]
psxy: Syntax error -f option. Correct syntax:
           Column information, add i for input, o for output [Default is both].
           <colinfo> is <colno>|<colrange>u, where column numbers start at 0
           a range is given as <first>-<last>, e.g., 2-5., u is type:
           t: relative time, T: absolute time, f: floating point,
           x: longitude, y: latitude, g: geographic coordinate.
psxy: Offending option 0g,1T

It seems illogical.

#8 Updated by Paul 5 months ago

On thing at the time here on the boat: The second question is an error in our parsing message: g has never meant geographic coordinate. It is a short hand for 0x,1y, that is why you may see a lot of -fg in commands where one must force geographic coordinates. The documentation has it right though. In r17370.
As for the first example, we will see if it is easy to detect this conflict between -f and -J

#9 Updated by Paul 5 months ago

Wait a second, how would we know that you meant 0x when you type 0y? Either would be valid, and if the latter there is no periodicity but degree symbols. Possibly some "bad" longitudes are skipped as well. Perhaps you can provide an example were you think GMT is misbehaving?

#10 Updated by Michael 5 months ago

I think, the problem in -JX option. This option can't see the difference between lon and lat, but -f can.
For example, I have a some data which depends on latitude, f(phi). I can plot it in two ways, phi on x-axis, f on y-axis or f on x-axis, phi on y-axis. But gmt behavior is completely different in these cases.
First case:
gmt psbasemap -P -R0/300/-1/1 -JX15cd/10c -f0y,1f -By1 -Bx50 -BWSne --FORMAT_GEO_MAP="+ddd:mm:ssF"
gmt plot degrees symbol on x-axis (0-300, this range is not valid for latitude!), but not respect --FORMAT_GEO_MAP.

Second case:
gmt psbasemap -P -R-1/1/0/300 -JX15c/10cd -f0f,1y -Bx1 -By50 -BWSne --FORMAT_GEO_MAP="+ddd:mm:ssF"
give the error
psbasemap: Internal Error = GMT_MAP_BAD_LAT_MAX
psbasemap (GMT_psbasemap): North is outside -90 to +90 degree range

which is right behavior and respect the --FORMAT_GEO_MAP if -R option is correct.

The same story with lons, they works correctly only if they are on the x-axis.

The another interesting example of -JX and -f interaction
echo "0 -40" |gmt psxy -P -R-1/1/0/90 -JX15c/10cd -f0f,1x -Bx1 -By50 -BWSne -Sc0.1i --FORMAT_GEO_MAP="+ddd:mm:ssF"
This command place the circle with respect to 360-periodicity, but --FORMAT_GEO_MAP is ignored.

Resume: I can say to gmt "interpret this column as longitude (latitude)", but I can't say "this x(y)-axis is latitude (longitude)".

Also available in: Atom PDF