# Srtm\_relief remote data set and NaN

**URL:** <https://forum.generic-mapping-tools.org/t/srtm-relief-remote-data-set-and-nan/5659>\
**Category:** Q&A\
**Created:** [December 27, 2024, 7:45pm UTC](https://forum.generic-mapping-tools.org/t/srtm-relief-remote-data-set-and-nan/5659 "2024-12-27T19:45:58Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Esteban82](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/esteban82/32/54_2.png) [@Esteban82](https://forum.generic-mapping-tools.org/u/Esteban82)\
**Post date:** [December 27, 2024, 7:45pm UTC](https://forum.generic-mapping-tools.org/t/srtm-relief-remote-data-set-and-nan/5659/1 "2024-12-27T19:45:58Z")

</div>

## Introduction

I made a map using the SRTM grid (which only contains land data) for the region covering the Dead Sea and the Mediterranean Sea. Since each sea has a different sea level, creating an accurate map can be challenging (as you can see in the examples below).

## Question

The SRTM data in the Mediterranean Sea originally contains NaN values. However, as far as I know, GMT replaces these NaN values with 0 during processing.

Wouldn’t it be better to keep the original NaN values instead of replacing them with 0? Are there cases where replacing NaN with 0 is necessary or beneficial?

If such cases exist, perhaps GMT could offer an option to let users decide whether to replace NaN values with 0 or keep them unchanged.

## Examples

`gmt grdimage @srtm_relief_03s -Baf -R34:30/35:45/31:30/32 -png DeadSea -Cgeo+h-414`

 ![DeadSea](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/2/25ec9c9772188f8393e89d18c762ae356775de2c.jpeg)

`gmt grdimage @srtm_relief_03s -Baf -R34:30/35:45/31:30/32 -png DeadSea`

 ![DeadSea](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/e/e51b007108c9571b33bf673d283249ea7dc5c369.jpeg)

---

<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:** [December 30, 2024, 8:19pm UTC](https://forum.generic-mapping-tools.org/t/srtm-relief-remote-data-set-and-nan/5659/2 "2024-12-30T20:19:39Z")

</div>

SRTM data originally came in a Int16 type, so no NaNs there. I don’t think (though I can be wrong) that GMT is guilty of setting the ocean (water as a matter of fact) data to zero.

---

<div class="post-metadata">

**Author:** ![Esteban82](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/esteban82/32/54_2.png) [@Esteban82](https://forum.generic-mapping-tools.org/u/Esteban82)\
**Post date:** [December 31, 2024, 12:59pm UTC](https://forum.generic-mapping-tools.org/t/srtm-relief-remote-data-set-and-nan/5659/3 "2024-12-31T12:59:25Z")

</div>

> [@Joaquim](#):
>
> I don’t think (though I can be wrong) that GMT is guilty of setting the ocean (water as a matter of fact) data to zero.

Ok, I have this impression because when I make a grid of the region of Israel (IL):  
`gmt grdcut @srtm_relief_03s -RIL -Ggrid.nc -V`

I got this message:  
`grdblend [INFORMATION]: 7377360 nodes assigned values, 306240 set to 0`

So, which nodes were assigned to 0? I thought it was the Sea/Ocean.