Load a DEM into QGIS

[acrosome]

I'm playing around with QGIS for the first time. I found out about The Global Land 1-km Base Elevation Project, and I wanted to import their datasets into QGIS, so that I can export it as a tiff or png for use in GIMP and Wilbur, but for the life of me I cannot figure out how to do it. I keep getting an error that the file type isn't supported. Any hints?

(Or, lacking that, any pointers to a similarly detailed heightmap for North America that is importable into Wilbur and Gimp?)

[acrosome]

Part of the problem, I guess, is that I can't even figure out what filetype the Global Land 1km Base Elevation data is. So I suspect that it may be something odd or proprietary. But, damn, just about everyone uses QGIS, right? You'd think it would be something compatible...

[Redrobes]

Usually its raw binary of integer or floating point data.

This doc:
https://www.ngdc.noaa.gov/mgg/topo/r...11/s11Fii.html

says that each tile comes with a doc or header file which states what the format is. Looking at the example shown it is binary integer type. Usually the integers are 16 bit. It says its 10800x4800 so the file is made up of about 50 million entries so its about 100MByte since uncompressed 16 bit integers is two bytes each.

Usually the datum is WGS84 (very rare to find global data using anything else but local data can often be different).

Says that the distance is 0.0083333 so thats 8mm per integer step. I am not sure if the 6098 is the integer value or the height after its been multiplied by the unit dist. It looks like there are no negative values so its height above mean sea level with no bathymetry and that if you see values of -500 they are flagged. Sometimes the data has holes in it and they have marked values to show you. Sometimes they fill them in with best guesses.

They have the min/max X/Y lat/lng range that the data covers.

Anyway if you files are 100Mb after unzipping then thats the likely format.

What you need to do is be able to set up the data type for import into Gis by telling it the row/column amounts and the format type which is probably 16 bit signed integer. Whether QGIS can easily do this I don't know.

[acrosome]

Thank you. I'll play around and see if that gives me enough hints to figure this out.

Yes, two of the tiles I downloaded are 101MB, but the other two are 126MB for some reason. The smaller ones are the northern ones whereas the larger ones are near the equator, so perhaps that has some thing to do with it since the pixels near the poles get stretched out?

Or, if you can figure out a different way to import this all into GIMP and Wilbur, I'm all ears. For instance, if there is something other than QGIS that seems appropriate.

[acrosome]

Ha! No luck with the Global Land 1-km Base Elevation Project data BUT... I found that GMTED2010 has even better data, at 7.5arcsec instead of 30arcsec. And I had no trouble importing and merging the files using Skalimoi's instructions here.

So, it all seemed to work... but now I can't find the damned output file! Grr.

But thanks, Redrobes. As always, you are a scholar and a gentleman. I tried to rep you, but I'm told that I have repped you too much already...

[woodb3kmaster]

So, it all seemed to work... but now I can't find the damned output file! Grr.

Unless you specify otherwise, QGIS normally outputs to a temporary scratch file. You can tell it to save the output to a file instead in the Merge options dialog, right above the "GDAL/OGR console call" text box. That text box should also tell you the location of your output file, even if it's a scratch file (those get sent to a folder in your AppData\Local\Temp folder if you're using Windows).

[acrosome]

Yes, I had actually figured some of that out. QGIS also doesn't like scales involving negative numbers (the file goes from -79 to 5634) or even 0, so I left that part on default and eventually got a file. Yay! But now when I load it into GIMP the TIF is incredibly faint. In fact I can only really see anything when I look at my screen at an acute angle from the side!

I think it may have something to do with the original data scale (above) and the TIF is 16 bit or something, since I had to leave the scale on default. Grrr. Not sure how I fix that.

EDIT-- Ha! I figured out how the scale function works! (It's different than the tutorial I was using.) You need four numbers after -scale, the min/max of the source file and the min/max of the output file that you want. And it will accept negative numbers. But I still got an incredibly faint output file. Grr.

EDIT AGAIN-- Wait! I had been misunderstanding the tutorial (which, frankly, could have used an example). So my source data scales from -79 to 5634. Thus, the scale command should be:

-scale -79 5634 0 65535

Now all is OK.

And GIMP defaults to a zoom of 1.56% to fit the whole 6.43GB monstrosity on the display. Mwa-ha-ha!

[Redrobes]

Great - glad you got that going. On the Gimp thing, I expect that its a 16 bit TIFF so that there is a lot of scope for more height if needed. I reckon at a guess that if you go to the adjust levels bit you can increase the contrast and it will show it fine. With a normal 8 bit greyscale image if you did that then most of the height image would be banded into just a few shades of grey. So you are stretching the levels from an image with 65536 shades of grey and displaying the relevant 256 of them. So if you move the range that the 256 covers then it will look better.

This is the reason why I prefer to use a file format for height data that is not raw or TIFF. Personally I use HF2 format but then not every app understands the HF2 / HFZ format so it can be a problem. If you have a file format that includes other data like the height range and the geographic meta data and datums etc then you dont have to specify them or enter them in and it travels with the file. But generally most people like NASA / NOAA etc use raw height data with separate file for the meta data describing it.