<p>If you can find a <a href="https://en.wikipedia.org/wiki/NetCDF" rel="nofollow noreferrer">NetCDF</a> file, I would recommend using it.  NetCDF is a very common self-documenting format with libraries widely available for any language that is suitable for scientific data analysis.  Global elevation data is commonly used and easily available. I've used the <a href="https://www.ngdc.noaa.gov/mgg/global/" rel="nofollow noreferrer">NOAA ETOPO</a> dataset, available as NetCDF or geotiff.</p>

<p>If you are using Python, I would recommend using <a href="http://xarray.pydata.org/en/stable/" rel="nofollow noreferrer">xarray</a>, but the lower level <a href="https://unidata.github.io/netcdf4-python/netCDF4/index.html" rel="nofollow noreferrer">netCDF4</a> is also quite good.  There is also interactive software to visualise NetCDF, such as <a href="https://www.giss.nasa.gov/tools/panoply/" rel="nofollow noreferrer">panoply</a>.</p>

CC BY-SA 4.0
2020-03-05T12:09:57.760Z
Thanks, gerrit. I edited the question in reply to your answer. So, (a)I'm programming in **C**, and (b)have already proceeded to the point where I'd rather continue using the NOAA-formatted data than start all over again. At some point, I might like to study that netcdf format more carefully, but I'm not seeing any straightforward documentation making that easy for newcomers (experienced programmer newcomers to the format). P.S. By the way, what other pronouns are there???:)
John Forkosh
CC BY-SA 4.0
2020-03-05T12:24:50.237Z
I can't help with the native format, but there are C libraries for netcdf. You may need to contact NOAA directly. P.S. See [here](https://lgbta.wikia.org/wiki/Neopronouns) or [here](https://nonbinary.wiki/wiki/English_neutral_pronouns).
gerrit
CC BY-SA 4.0
2020-03-06T13:21:25.790Z
Thanks again, gerrit.  I took a look at some of the examples at https://www.unidata.ucar.edu/software/netcdf/Contrib.html and elsewheres, but it still looks like a non-trivial investment of time to get comfortable with the format and libraries/tools. (At some point it's somewhat likely that I'll get around to it, but that point's probably not today.)
John Forkosh
CC BY-SA 4.0
2020-03-05T09:04:20.467Z
2020-03-05T12:09:21.723Z
2020-03-05T12:09:21.723Z
gerrit
<p>I've downloaded the <strong>all10g</strong> data from <a href="https://www.ngdc.noaa.gov/mgg/topo/gltiles.html" rel="nofollow noreferrer">https://www.ngdc.noaa.gov/mgg/topo/gltiles.html</a> <br>
and also the <strong>globedocumentationmanual.pdf</strong> from the "The Globe Project Report" link on that page.</p>

<p>The only relevant format info I see there is on pages#82 (the 90th page) through 85.<br>
Are there any other relevant pages in that manual I'm overlooking, or,<br>
better yet, some other more comprehensive description of the data format elsewhere?</p>

<p>As far as pages#82-85 is concerned...<br>
 &nbsp; &nbsp; Firstly, the 16-bit little-endian stuff is no problem at all.<br></p>

<p>&nbsp; &nbsp; As best I can determine, the data is organized as follows:</p>

<pre><code>   +--------------------------------------------+
   |   &lt;-- 10800 cols for 90deg longitude --&gt;   | ^
   |       = 30 arcsec per col resolution       | | 4800rows
   |                                      ^     | | for 40deg lat,
   |       and 4800/40 or 6000/50 is also |     | | or 6000 for 50
   |       = 30 arcsec per row resolution |     | v
   +--------------------------------------v-----+
</code></pre>

<p>Is this correct? Or are we talking about some other kind of projection (e.g., mercator) of the Earth's surface onto a plane rectangular grid? And am I correct in assuming that the 10800 longitude cols, even at high latitudes, is simply a waste of space (presumably for simplicity/consistency of format)?</p>

<p>Also, exactly how do you stitch the tiles together at their boundaries? For example, if you wanted to represent 0-to-90 degrees in one-degree intervals, you'd need 91 points, not 90, in order to cover both the 0 and the 90 boundary points. So the page#83 "Table 3. Tile Definitions", e.g.,</p>

<pre><code>A10G   min lat=50 max=90   min lon=-180 max=-90   
</code></pre>

<p>presumably isn't covering <strong>both</strong> the 50 and 90 lat min/max boundary points. So which one? Or what, exactly?</p>

<p><br><strong>Aside:</strong> while rummaging through the open data sites for elevation data, I also came across
<a href="https://lpdaac.usgs.gov/product_search/?keyword=Elevation&amp;view=cards&amp;sort=title" rel="nofollow noreferrer">https://lpdaac.usgs.gov/product_search/?keyword=Elevation&amp;view=cards&amp;sort=title</a>
(then choose NASADEM_HGT v001), which seems to be in this pretty-widely-used netcdf (or variants like netcdf4) format, which I hadn't heard of before. Its format seems to be somewhat discussed at, e.g., <a href="https://www.researchgate.net/post/Extracting_data_from_a_netCDF_file" rel="nofollow noreferrer">https://www.researchgate.net/post/Extracting_data_from_a_netCDF_file</a> (and several similar), but I haven't been able to google a nice, concise, meant-for-programmers discussion. Can you point me to one? Thanks.</p>

<p><br> <strong>&nbsp; &nbsp; E d i t</strong> <br> <strong>--------------</strong> <br>
In response to @gerrit's reply below, I already looked over the netcdf format info, as best I could, and will maybe eventually study it more carefully. But that will clearly take lots more time (at least for me) than just dealing with the NOAA format, as discussed above.</p>

<p>My programming is in <strong>C</strong>, and I've already pretty much dealt with that format, as illustrated by the gif below,
<a href="https://i.sstatic.net/XNusz.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XNusz.gif" alt="enter image description here"></a>
created directly from the f10g file, just as a test.
The temporary test colors are</p>

<pre><code>  /* --- colorkey --- */
  int colorkey[99] = {
          0*256 +  4,           /* sea surface and below is 4=blue */
        100*256 + 11,           /* up to 100m is 11=green */
        250*256 +  5,           /* up to 250m is yellow */
        500*256 + 10,           /*  500 maroon */
       1000*256 +  2,           /* 1000 red */
       2500*256 +  8,           /* 2500 gray */
      10000*256 +  9,           /* rest silver */
                  -1 };
</code></pre>

<p>The eventual goal, which really isn't that much more complicated,<br>
is to generate a gif animation, where each successive frame shows
what happens when sea level rises, say, another foot.</p>

<p>In any case, a quick glance at the gif suggests that my naive interpretation of the data's lat,lon grid is, in all likelihood, generally more-or-less correct. And I probably don't need anything more accurate/precise for the intended purpose. But it would be nice (and I'd still like) to have more thorough documentation than what's cited above. Anybody have that info, or just a link to it would be great. Thanks.</p>

<p><br> <strong>&nbsp; &nbsp; E d i t # 2</strong> <br> <strong>------------------</strong> <br>
Just to illustrate the intended use, below's an animation, focusing on the Florida region of the f10g tile. Each successive frame raises sea level (actually, lowers the elevation of each land pixel, leaving ocean unchanged) by one meter. The first frame is raw data, and there are 30 frames in all, and then repeat. Of course, one meter times 30 is kind of extreme, but the NOAA data's in meters, so I don't immediately have any finer vertical resolution available. And it's just a prototype illustration (but I know where I'm buying my retirement home:).
<a href="https://i.sstatic.net/X5QIB.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/X5QIB.gif" alt="enter image description here"></a>
The colortable/colorkey is also different than the first gif above,
with light_green-->dark_green for the first twelve meters, and then yellow up to 100 meters, as follows<br></p>

<pre><code>  int colorkey2[99] = {
          0*256 +  0,           /* sea surface and below is 0=blue */
          1*256 +  1,           /* 1-12 meters are shades of green */
          2*256 +  2,           /*  "  */
          3*256 +  3,           /*  "  */
          4*256 +  4,           /*  "  */
          5*256 +  5,           /*  "  */
          6*256 +  6,           /*  "  */
          7*256 +  7,           /*  "  */
          8*256 +  8,           /*  "  */
          9*256 +  9,           /*  "  */
         10*256 + 10,           /*  "  */
         11*256 + 11,           /*  "  */
         12*256 + 12,           /*  "  */
        100*256 + 13,           /*  yellow up to 100 meters */
        500*256 + 14,           /*  red 500 */
      99999*256 + 15,           /*  silver higher */
</code></pre>

CC BY-SA 4.0
2020-03-06T13:13:54.730Z
@BarryCarter Thanks. Why didn't I think of that???:) Sure, sounds obvious now that you've said it. And, although I still haven't been able to find it explicitly documented that way, I don't even care so much if it's exactly right. Just so I can neatly "stitch" together those NOAA tiles without leaving any blank/undefined cells, and have the entire grid go smoothly across the boundary from one tile to the next..
John Forkosh
CC BY-SA 4.0
2020-03-08T02:04:43.863Z
I've added your scary GIF to [How soon will LC-39A be at significant risk to storm-surge damage?]
(https://space.stackexchange.com/q/31810/12102) and unaccepted my answer in case you'd like to add a science and/or prediction-based answer.
uhoh
CC BY-SA 4.0
2020-03-08T06:48:57.340Z
@uhoh Happy to hear the gif found some useful purpose. But go ahead and re-accept your answer (i.e., your own answer:), which I upvoted, which seems well-researched and -documented. Especially seeing as it mentions GISS, where I actually worked for a few years during the mid-1970's and then again in the early 1980's.
John Forkosh
CC BY-SA 4.0
2020-03-08T07:39:29.520Z
@JohnForkosh since editing puts the question back into the active queue, I'll leave it open for a while in case further answers are forthcoming. *Thanks!*
uhoh
<open-data><data-formats>
Format/interpretation of NOAA Elevation Data
John Forkosh
# Format/interpretation of NOAA Elevation Data

(Asked by: username_0 on 2020-03-05)

I've downloaded the **all10g** data from <https://www.ngdc.noaa.gov/mgg/topo/gltiles.html>   
and also the **globedocumentationmanual.pdf** from the "The Globe Project Report" link on that page.

The only relevant format info I see there is on pages#82 (the 90th page) through 85.  
Are there any other relevant pages in that manual I'm overlooking, or,  
better yet, some other more comprehensive description of the data format elsewhere?

As far as pages#82-85 is concerned...  
    Firstly, the 16-bit little-endian stuff is no problem at all.

    As best I can determine, the data is organized as follows:

```
   +--------------------------------------------+
   |   <-- 10800 cols for 90deg longitude -->   | ^
   |       = 30 arcsec per col resolution       | | 4800rows
   |                                      ^     | | for 40deg lat,
   |       and 4800/40 or 6000/50 is also |     | | or 6000 for 50
   |       = 30 arcsec per row resolution |     | v
   +--------------------------------------v-----+

```

Is this correct? Or are we talking about some other kind of projection (e.g., mercator) of the Earth's surface onto a plane rectangular grid? And am I correct in assuming that the 10800 longitude cols, even at high latitudes, is simply a waste of space (presumably for simplicity/consistency of format)?

Also, exactly how do you stitch the tiles together at their boundaries? For example, if you wanted to represent 0-to-90 degrees in one-degree intervals, you'd need 91 points, not 90, in order to cover both the 0 and the 90 boundary points. So the page#83 "Table 3. Tile Definitions", e.g.,

```
A10G   min lat=50 max=90   min lon=-180 max=-90   

```

presumably isn't covering **both** the 50 and 90 lat min/max boundary points. So which one? Or what, exactly?

**Aside:** while rummaging through the open data sites for elevation data, I also came across
<https://lpdaac.usgs.gov/product_search/?keyword=Elevation&view=cards&sort=title>
(then choose NASADEM\_HGT v001), which seems to be in this pretty-widely-used netcdf (or variants like netcdf4) format, which I hadn't heard of before. Its format seems to be somewhat discussed at, e.g., <https://www.researchgate.net/post/Extracting_data_from_a_netCDF_file> (and several similar), but I haven't been able to google a nice, concise, meant-for-programmers discussion. Can you point me to one? Thanks.

**E d i t**   
 **--------------**   
In response to @username_2's reply below, I already looked over the netcdf format info, as best I could, and will maybe eventually study it more carefully. But that will clearly take lots more time (at least for me) than just dealing with the NOAA format, as discussed above.

My programming is in **C**, and I've already pretty much dealt with that format, as illustrated by the gif below,
[![enter image description here](https://i.sstatic.net/XNusz.gif)](https://i.sstatic.net/XNusz.gif)
created directly from the f10g file, just as a test.
The temporary test colors are

```
  /* --- colorkey --- */
  int colorkey[99] = {
          0*256 +  4,           /* sea surface and below is 4=blue */
        100*256 + 11,           /* up to 100m is 11=green */
        250*256 +  5,           /* up to 250m is yellow */
        500*256 + 10,           /*  500 maroon */
       1000*256 +  2,           /* 1000 red */
       2500*256 +  8,           /* 2500 gray */
      10000*256 +  9,           /* rest silver */
                  -1 };

```

The eventual goal, which really isn't that much more complicated,  
is to generate a gif animation, where each successive frame shows
what happens when sea level rises, say, another foot.

In any case, a quick glance at the gif suggests that my naive interpretation of the data's lat,lon grid is, in all likelihood, generally more-or-less correct. And I probably don't need anything more accurate/precise for the intended purpose. But it would be nice (and I'd still like) to have more thorough documentation than what's cited above. Anybody have that info, or just a link to it would be great. Thanks.

**E d i t # 2**   
 **------------------**   
Just to illustrate the intended use, below's an animation, focusing on the Florida region of the f10g tile. Each successive frame raises sea level (actually, lowers the elevation of each land pixel, leaving ocean unchanged) by one meter. The first frame is raw data, and there are 30 frames in all, and then repeat. Of course, one meter times 30 is kind of extreme, but the NOAA data's in meters, so I don't immediately have any finer vertical resolution available. And it's just a prototype illustration (but I know where I'm buying my retirement home:).
[![enter image description here](https://i.sstatic.net/X5QIB.gif)](https://i.sstatic.net/X5QIB.gif)
The colortable/colorkey is also different than the first gif above,
with light\_green-->dark\_green for the first twelve meters, and then yellow up to 100 meters, as follows

```
  int colorkey2[99] = {
          0*256 +  0,           /* sea surface and below is 0=blue */
          1*256 +  1,           /* 1-12 meters are shades of green */
          2*256 +  2,           /*  "  */
          3*256 +  3,           /*  "  */
          4*256 +  4,           /*  "  */
          5*256 +  5,           /*  "  */
          6*256 +  6,           /*  "  */
          7*256 +  7,           /*  "  */
          8*256 +  8,           /*  "  */
          9*256 +  9,           /*  "  */
         10*256 + 10,           /*  "  */
         11*256 + 11,           /*  "  */
         12*256 + 12,           /*  "  */
        100*256 + 13,           /*  yellow up to 100 meters */
        500*256 + 14,           /*  red 500 */
      99999*256 + 15,           /*  silver higher */

```

**Tags:** open-data, data-formats

> **Comments:**
> **username_0**: @BarryCarter Thanks. Why didn't I think of that???:) Sure, sounds obvious now that you've said it. And, although I still haven't been able to find it explicitly documented that way, I don't even care so much if it's exactly right. Just so I can neatly "stitch" together those NOAA tiles without leaving any blank/undefined cells, and have the entire grid go smoothly across the boundary from one tile to the next..  
> **username_1**: I've added your scary GIF to [How soon will LC-39A be at significant risk to storm-surge damage?] (https://space.stackexchange.com/q/31810/12102) and unaccepted my answer in case you'd like to add a science and/or prediction-based answer.  
> **username_0**: @username_1 Happy to hear the gif found some useful purpose. But go ahead and re-accept your answer (i.e., your own answer:), which I upvoted, which seems well-researched and -documented. Especially seeing as it mentions GISS, where I actually worked for a few years during the mid-1970's and then again in the early 1980's.  
> **username_1**: @username_0 since editing puts the question back into the active queue, I'll leave it open for a while in case further answers are forthcoming. *Thanks!*  

---

## 1 answers

### Answer by username_2 on 2020-03-05. Score: 4

If you can find a [NetCDF](https://en.wikipedia.org/wiki/NetCDF) file, I would recommend using it. NetCDF is a very common self-documenting format with libraries widely available for any language that is suitable for scientific data analysis. Global elevation data is commonly used and easily available. I've used the [NOAA ETOPO](https://www.ngdc.noaa.gov/mgg/global/) dataset, available as NetCDF or geotiff.

If you are using Python, I would recommend using [xarray](http://xarray.pydata.org/en/stable/), but the lower level [netCDF4](https://unidata.github.io/netcdf4-python/netCDF4/index.html) is also quite good. There is also interactive software to visualise NetCDF, such as [panoply](https://www.giss.nasa.gov/tools/panoply/).

> **Comments:**
> **username_0**: Thanks, username_2. I edited the question in reply to your answer. So, (a)I'm programming in **C**, and (b)have already proceeded to the point where I'd rather continue using the NOAA-formatted data than start all over again. At some point, I might like to study that netcdf format more carefully, but I'm not seeing any straightforward documentation making that easy for newcomers (experienced programmer newcomers to the format). P.S. By the way, what other pronouns are there???:)  
> **username_2**: I can't help with the native format, but there are C libraries for netcdf. You may need to contact NOAA directly. P.S. See [here](https://lgbta.wikia.org/wiki/Neopronouns) or [here](https://nonbinary.wiki/wiki/English_neutral_pronouns).  
> **username_0**: Thanks again, username_2.  I took a look at some of the examples at https://www.unidata.ucar.edu/software/netcdf/Contrib.html and elsewheres, but it still looks like a non-trivial investment of time to get comfortable with the format and libraries/tools. (At some point it's somewhat likely that I'll get around to it, but that point's probably not today.)  

---

