Grdview issue in GMT 6.1 over 180° Longitude

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 >

The grd file is available here:

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
Stack backtrace:

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

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

grdimage @earth_relief_15m -Cgeo -JQ10 -R130/-40.2/-112/36.0790121389r >
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 >
grdimage [ERROR]: Option -R parsing failure. Correct syntax:

because west > east

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 >

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:
It doesn’t work in GMT 6.1, only in GMT 6.0.1, with:

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

Oliver Matz

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

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.

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 >

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

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

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

Oliver Matz