I am building a JavaScript script that reads binary HGT files - as generated by the SRTM - and converts the data into bitmaps viewable in your browser.

You can try out the script and view the source code of a preliminary version on GitHub:


The app seems to be reading the elevation data correctly, but the numbers are huge ( over 20>). See the demo which shows the first 50 heights of the file. In this case, the demo shows the southern tip of Point Reyes near San Francisco CA.

The SRTM 'Quickstart Guide' says:

Heights are in meters referenced to the WGS84/EGM96 geoid

I cannot find a definition or explanation for what this exactly means. Nor have I found any JavaScript code that could be used to convert the 16 bit integer HGT data into something like meters of elevation above or below sea level.

  • Welcome to Gis.SE. Have you looked at gis.stackexchange.com/questions/43743/… - in particular that the heights are big endian? – BradHards Mar 21 '14 at 3:31
  • 1
    this post could also help once you've solved the big endian issue. gis.stackexchange.com/questions/11672/… – radouxju Mar 21 '14 at 6:37
  • @BradHards Bingo! I was thrown off by the geoid thing. I imagined it was some complex GIS equation thingy. I guess it just means 'imagine a sea level where you are'. Anyway, I found a way to switch the ends. New rev of the app will be up shortly - with this issue solved – Theo Mar 21 '14 at 22:13
  • @radouxju Thanks for the link. Some good suggestions. I am already a GDAL user and think it's terrific. In this case, however, the issue is about building a new 3D app - one that works in your browser - with code any beginner coder can tweak - accessing heightmaps for the entire globe. The first generation is already up on GitHub: jaanga.github.io/terrain – Theo Mar 21 '14 at 22:15

From the comment discussion:

There are a range of issues discussed in previous questions:

It is particularly important to note that HGT file format is a pretty raw format, essentially just 16 bit integer values. However reading those values as 16 bit integer values on many machines will treat them as little endian format, while the actual format is big endian.

One option would be to read them as pairs of bytes, and bit shift / add.


A new revision of the app is up on GitHub with the big endian byte swap issue dealt with. See:

Read HGT Files R2.

@BradHards pointed me in the right direction.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.