This object is in archive! 

HGT files in \data\strm are inaccurate

Nick Suter shared this problem 8 years ago
Not a Problem

Using Locus Pro 3.15.1


I've downloaded 30m/1arc-second 25MB HGT SRTM file S45E168.hgt and installed to \data\strm

I can tell it is loading because I can see altitudes instantly at the cursor as I move around.

SRTM v3 Sept 2014 Void-Filled "SRTM Plus"http://earthexplorer.usgs.gov/


However, the altitude is out. At the point shown below, 2830m, it is ~46m out.

Location below is http://www.topomap.co.nz/NZTopoMap?v=2&ll=-44.62392,168.39691&z=14

dc10f8c4ab1a99e873a07fca88cd7ca6


Even with everything turned on or off in Altitude Manager, the altitudes are out.


The altitudes are correct when there is only a WW15MGH.DAC (locus downloaded) file & there are NO HGT files. However there is a delay showing the altitude on the crosshair, and I do not know if it works offline, or how accurate it is (its only a 2MB File).


Is it possibly this issue: http://stackoverflow.com/questions/9249193/how-to-calculate-the-altitude-above-from-mean-sea-level

Replies (7)

photo
1

Forgot to mention, you can also download the NZ topo's from that same topomap.co.nz URL given in the first post

Just click More -> Downloads. Then left click near the Mt Earnslaw to download:


Garmin Custom Map / Google Earth overlay (KMZ file)


The same issue exists if you use the Locus Online Map "NzTopoMaps" (to rule out the KMZ being wrong).

photo
1

Hello Nick,

firstly how it works: if you clear the /data/srtm folder and enable dynamic altitudes then Locus loads elevation data from Google's web service. These the reason why it takes some time to display the value. If you put any HGT file into /data/srtm that covers area of interest then Locus loads data from this HGT file.

As is mentioned in Stackowerflow link WW15MGH.DAC file is quite vital if you want to sea real altitudes. Honestly I didn't try your hgt file but I've downloaded hgt file via new Point in Locus - see. =get&s[]=altitude#download_altitude_file_when_placing_or_editing_a_point_of_interest]http://docs.locusmap.eu/doku.php?id=manual:faq:how_to_add_map_shading&s[]=get&s[]=altitude#download_altitude_file_when_placing_or_editing_a_point_of_interest

We use 3 arc data that are not so detailed as your 1arc data but on files are distributed via viewfinderpanoramas site. You can see from attached screenshot that I have little bit different value.

However we should consider how are elevation data structured. The HGT files are not able to describe all peak or some quick elevation changes. Data itself are created as rectangular grid so you need interpolate the grid values to get elevation for specific point. For this reason are the peaks almost inaccurate (due to interpolation from surrounding grid values). On the other side this complication is related only with peaks, cliff, overhang etc. We also need to mention that accuracy of data itself is about 5 - 10m. More over as I know SRTM data itself were low accurate in mountains areas. This is reason why we use viewfinderpanoramas data.

Finally there is no problem in Locus from my point of view. You have only found the weakness of HGT data. Thank for understanding

Best regards

Petr

photo
1

I appreciate the reply and understand your reasoning, however when the HGT is loaded into QGIS, the data shows:


The point is 2785

The next highest elevation contour is 2780.


So the data matches what Locus shows for me when I use the HGT file.

QGIS, using HGT file as a raster layer, very zoomed in on East Peak 2830.

d37eeabd34171307a7fda264ab2bff9a


So the data in the HGT doesn't have a hole, or is inaccurate as you propose. The point is even very clearly captured (at the right location too).


I still believe the data is correct, but I still feel like Locus is not converting or extrapolating the data correctly. Perhaps the data in the HGT needs correcting for a different ellipsoid (or something)...

photo
1

Hello Nick,


I'm testing what you wrote above in Locus and:


- resolution of NZ maps is in best case few metres (maybe around 10 metres)

- when you will move with Locus map center around peak, you may notice that elevation raise up to 2815 m, which is a lot better then I expected

- when you move with a map center over contour lines, they match quite well as well


So sorry, to be true I'm surprised how precise Locus is and agree with Petr.

photo
1

No, I do not see more than 2784. I've moved all around the peak! Even 100n away (where it is much lower). This is the highest I get with my SRTM hgt file:

photo
1

Exactly on place of your screenshot, I have value around 20 metres higher. So please remove downloaded file and download file directly over Locus as Petr mentioned before.

photo
1

Yeah wow, west peak is over 300m incorrect. I notice the flatter the terrain, the more accurate locus is. Small peaks on almost flat terrain are almost perfect. I wonder if locus factors in too many points when trying to interpolate the height? Using to many lower points around the peaks, lowering the competed values?

photo
1

So the solution is to use inferior, less accurate data because locus can truly determine the proper altitudes from more precise data? Given the fact locus can use the high resolution file indicates to the user it will correctly indicate altitude - which it does not.

photo
1

This is weird nick. I'm testing it more precisely, because I really don't like unsolved mysteries :).

Test location: -44.622504, 168.410584

From "Locus" HGT, Locus interpolate height from following four values:


  1. altBL = 2702.0
  2. altBR = 2734.0
  3. altTL = 2812.0
  4. altTR = 2817.0

In case of your file, Locus interpolate from:


  1. altBL = 2774.0
  2. altBR = 2783.0
  3. altTL = 2784.0
  4. altTR = 2783.0

When I enable shading of map, it looks like Locus compute values correctly (so there seems to be no problem like incorrect search in file etc.). Interesting is that for example "West Peak" two kilometres to west should be 2820 m height, but Locus display just 2500 m!! A log bigger difference.

Hard to say how may I help you here Nick .. check please also in QGis coordinates -44.62559 , 168.39531 (coordinates of mentioned "West Peak". Difference here is really huge.


EDIT: I've just computed also difference between geoid and ellipsoid and it seems to be here just around 4 metres

photo
1

Oops sorry, I replied above.

Replies have been locked on this page!