Grdview issue in GMT 6.1 over 180° Longitude

Q&A
1

I want to use the following grdview statement:

gmt grdview ./Elev15.grd -Cgeo -Qs -Xa-2c -Ya-2c -JM0/0/32.7c -R130/-40.2/-112/36.0790121389r > Map.ps

The grd file is available here: https://www.file-upload.net/download-14220428/Elev15.grd.html

It fails with the following message
grdview (gmtapi_import_grid): Could not reallocate memory [4976.00 Gb, 1335734529874 items of 4 bytes]
grdview (gmtnc_grd_prep_io): Subset x range <= 0.0 [./Elev15.grd]
ERROR: Caught signal number 11 (Segmentation fault) at
/lib/x86_64-linux-gnu/libc.so.6(+0x18ef51)[0x7f4f4da6ef51]
[0x0]
Stack backtrace:
/opt/GMT/lib/libgmt.so.6(sig_handler+0x2b1)[0x7f4f4df2b221]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7f4f4dce38a0]
/lib/x86_64-linux-gnu/libc.so.6(+0x18ef51)[0x7f4f4da6ef51]
/opt/GMT/lib/libgmt.so.6(gmt_nc_read_grd+0xa26)[0x7f4f4dfb7636]
/opt/GMT/lib/libgmt.so.6(gmtlib_read_grd+0x1df)[0x7f4f4df91d3f]
/opt/GMT/lib/libgmt.so.6(+0x61d2d)[0x7f4f4df51d2d]
/opt/GMT/lib/libgmt.so.6(GMT_Read_Data+0xd72)[0x7f4f4df5c252]
/opt/GMT/lib/libgmt.so.6(GMT_grdview+0x1eaa)[0x7f4f4e1ec38a]
/opt/GMT/lib/libgmt.so.6(GMT_Call_Module+0x206)[0x7f4f4df44106]
gmt(main+0x6cf)[0x55dc94a516cf]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f4f4d901b97]
gmt(_start+0x2a)[0x55dc94a521aa]

It worked with GMT 6.0 (I have simplified the call, but it should still show the issue)

Any ideas where to start troubleshooting?

Thanks for the great GMT!

Oliver Matz

2

The problem is in your -R and the error skips undetected

grdimage @earth_relief_15m -Cgeo -JQ10 -R130/-40.2/-112/36.0790121389r > Map.ps
grdimage (gmtapi_import_grid): Could not reallocate memory [4960.00 Gb, 1331439562920 items of 4 bytes]
grdimage (gmtnc_grd_prep_io): Subset x range <= 0.0 [c:/j/.gmt/server/earth/earth_relief/earth_relief_15m_p.grd]

more clear

grdimage @earth_relief_15m -Cgeo -JQ10 -R130/-112/-40.2/36.0790121389 > Map.ps
grdimage [ERROR]: Option -R parsing failure. Correct syntax:
        -R<xmin>/<xmax>/<ymin>/<ymax>[/<zmin>/<zmax>]

because west > east

3

Hi Joaquim.
Thanks for your support. Unfortunately, we create several maps, that span across the 180°W/E. So we add the “r” to the -R option, to give lower left and upper right corner. The lower left is on the Eastern Hemisphere and the upper right is on the Western hemisphere. The following example works fine:

gmt grdview @earth_relief_15m -Cgeo -JL177.7/44.5/20.36/56.74/32.7c -R130/-40.2/-112/36.0790121389r > Map.ps

It uses the same -R option as in my first post, only the projection changed from Mercator to Lambert projection. With GMT 6.0.1 I was able to produce good results with the Mercator projection as well.

Thanks for simplifying my example with the @earth_relief_15m and by removing the additional options.

So, to summarize. The call works in GMT 6.0.1 and 6.1 with:
-JL177.7/44.5/20.36/56.74/32.7c
It doesn’t work in GMT 6.1, only in GMT 6.0.1, with:
-JM0/0/32.7c

Do you have any idea, how to fix or work around this?

Oliver Matz

4

I have no recall that it has ever worked with west > east. What I’m implying is that you must give west < east. like in

gmt grdimage @earth_relief_15m -Cgeo -JL177.7/44.5/20.36/56.74/32.7c -R-230/-40.2/-112/36.0790121389r -png Map

that works fine

5

It should be possible to relax this a bit for some projections, such as Mercator, by ensuring east > west by adding 360. For others, especially the oblique, we cannot do so but they are mostly OK with this. I am testing a patch that lest the rectangular cylindrical projections tolerate such reversals.

6

Note that we already handle many of these cases by using teh full longitude specification:

This works fine:
gmt pscoast -JM22.7c -R130E/112W/-40.2/36.0790121389 -Gred -Baf > t.ps

This fails:
gmt pscoast -JM22.7c -R130/-112/-40.2/36.0790121389 -Gred -Baf > t.ps

The principle was that the first case you know what you are doing, but the second could be random typing.

7

Thank you Paul.
Using the full longitude specification solves my problem and improves readability.

Oliver Matz