Skip to content
Terrainly Open viewer

Troubleshooting · 6 min read

GeoTIFF won’t load? Fix common DEM errors

Most problems come down to a handful of causes. Find the message you saw (or the symptom you’re seeing) below, with the fix in QGIS or GDAL.

First, look inside the file. If you have GDAL installed, gdalinfo yourfile.tif prints its size, coordinate system, NoData value and compression, which answers most of the questions below. In QGIS, open Layer Properties → Information.

Messages you might see

“This looks like a colour image (RGB), not an elevation model.”

The file has three or more bands. That’s an aerial photo or orthomosaic, not a DEM. Export the elevation product from your processing software instead; it is usually called DSM, DTM or DEM and has a single band.

“This file’s coordinate system … isn’t supported yet”

The viewer knows about 6,000+ coordinate systems, but a few exotic or custom ones aren’t usable. Reproject the file to something common, such as WGS 84 (EPSG:4326) or the UTM zone for your area:

gdalwarp -t_srs EPSG:4326 input.tif output.tif

In QGIS: Raster → Projections → Warp (Reproject). Use a bilinear resampling method for elevation data, not “nearest”.

“This GeoTIFF is rotated or sheared”

The grid isn’t aligned with north. Resample it onto a regular north-up grid:

gdalwarp -r bilinear input.tif output.tif

“This file has no georeferencing, so it can’t be placed on the map.”

The file contains pixels but no information about where on Earth they belong. The viewer still draws it near the map’s current center so you can inspect it. To fix it properly, assign a location in QGIS with the Georeferencer, or set the coordinate system if you know it: gdal_edit.py -a_srs EPSG:32618 input.tif (this only labels the file; it must also have correct corner coordinates).

“This file has no valid elevation values (everything is NoData).”

Every cell matches the file’s NoData value. That usually means the NoData value was set wrongly (for example 0 on a coastal DEM where sea level really is 0). Check with gdalinfo -stats input.tif, and clear or correct the value with gdal_edit.py -unsetnodata input.tif or gdal_edit.py -a_nodata -9999 input.tif.

“This file uses a compression method (TIFF code …) that can’t be read in the browser.”

Uncompressed, LZW, DEFLATE, ZSTD, PackBits, LERC and JPEG work. Anything else (JPEG 2000, WebP and so on) doesn’t. Re-save it with a common method:

gdal_translate -co COMPRESS=DEFLATE input.tif output.tif

“Could not read this file as a GeoTIFF: …”

The file isn’t a valid TIFF. It may be a different format with a .tif name, or it may be damaged or only partly downloaded. If it’s an Esri ASCII grid, SRTM .hgt or Erdas .img file, convert it:

gdal_translate input.hgt output.tif

“Couldn’t convert this file’s coordinates to the map”, “too close to the poles”, “spans too wide an area”

The map is a standard web map, which can’t show the poles or a raster covering most of the globe. Polar datasets (for example in EPSG:3413 or EPSG:3031) need to be reprojected and cropped to a smaller regional area first.

Symptoms with no message

It loads, but looks flat or all one color

  • A few extreme values (a spike, or an undeclared NoData such as -9999) are stretching the color scale. Press Trim 2–98% or type your own elevation range.
  • The terrain really is flat. Raise Vertical exaggeration to 5× or more, and lower the sun.

The heights look wrong by a factor of about 3

Feet and metres. The viewer converts when the file declares feet or uses a feet-based coordinate system. If a metric file secretly contains feet, nothing in the file says so, and the heights are shown as metres. Multiply by 0.3048 to convert:

gdal_calc.py -A input.tif --outfile=output.tif --calc="A*0.3048"

It shows up in the wrong place

The viewer trusts the coordinate system stored in the file. If that label is wrong, the terrain lands somewhere else. Open the file in QGIS next to a basemap to confirm, then correct the label or reproject.

It’s blurrier than I expected

Rasters above about 16 million cells are shown as a reduced-resolution preview, made by averaging blocks of cells. The Details panel shows a “Preview” row when this happens, and hover readings are then averages over each block. Crop the file to the area you care about to see it at full resolution:

gdal_translate -projwin ulx uly lrx lry input.tif cropped.tif

(The four numbers are the upper-left and lower-right corners in the file’s own coordinates.)

The tab is slow or crashes

Very large files need a lot of memory, and phones have much less than laptops. Crop the file, close other tabs, or try a desktop browser.

Hovering shows no elevation

You’re over a NoData cell (shown transparent) or outside the file’s extent.

Still stuck?

Check the step-by-step guide, or try the viewer with the built-in sample first to rule out a browser problem.

Open the viewer →