# Grdview issue in GMT 6.1 over 180° Longitude

**URL:** <https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749>\
**Category:** Q&A\
**Created:** [August 6, 2020, 2:08pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749 "2020-08-06T14:08:37Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![MatzIT](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/matzit/32/38_2.png) [@MatzIT](https://forum.generic-mapping-tools.org/u/MatzIT)\
**Post date:** [August 6, 2020, 2:08pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/1 "2020-08-06T14:08:37Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\
**Post date:** [August 6, 2020, 4:11pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/2 "2020-08-06T16:11:22Z")

</div>

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

```auto
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

```auto
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`

---

<div class="post-metadata">

**Author:** ![MatzIT](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/matzit/32/38_2.png) [@MatzIT](https://forum.generic-mapping-tools.org/u/MatzIT)\
**Post date:** [August 6, 2020, 9:05pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/3 "2020-08-06T21:05:23Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\
**Post date:** [August 6, 2020, 10:08pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/4 "2020-08-06T22:08:44Z")

</div>

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

```auto
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

---

<div class="post-metadata">

**Author:** ![pwessel](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/pwessel/32/30_2.png) [@pwessel](https://forum.generic-mapping-tools.org/u/pwessel)\
**Post date:** [August 7, 2020, 2:11am UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/5 "2020-08-07T02:11:18Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pwessel](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/pwessel/32/30_2.png) [@pwessel](https://forum.generic-mapping-tools.org/u/pwessel)\
**Post date:** [August 7, 2020, 2:23am UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/6 "2020-08-07T02:23:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MatzIT](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/matzit/32/38_2.png) [@MatzIT](https://forum.generic-mapping-tools.org/u/MatzIT)\
**Post date:** [August 7, 2020, 12:16pm UTC](https://forum.generic-mapping-tools.org/t/grdview-issue-in-gmt-6-1-over-180-longitude/749/7 "2020-08-07T12:16:29Z")

</div>

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

Oliver Matz