HGT files in \data\strm are inaccurate
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
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
The same problem 
HGT file for you:
https://www.dropbox.com/s/58lg6m7o1r1gau5/S45E168.hgt?dl=0
HGT file for you:
https://www.dropbox.com/s/58lg6m7o1r1gau5/S45E168.hgt?dl=0
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).
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).
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
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
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.
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)...
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.
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)...
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.
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.
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.
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.
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:
In case of your file, Locus interpolate from:
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
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:
In case of your file, Locus interpolate from:
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
Replies have been locked on this page!