Hi guys,
first of all, i know the altitude manager in Locus, STRM files, barometric and gps stuff a.s.o. to get altitude values out of Locus.
In the heart of middle Frankonia sometimes i used to do trailrunning and want to know the exact altitude differences to plan my routes.
As you can see on osm (http://www.openstreetmap.org/#map=16/49.3518/11.2162&layers=C) there is a small canyon called Schwarzachklamm with a bridge (http://www.hansgruener.de/docs_d/kanal_ak/brueckkanal_1647_0303.htm) 18m in height and the canyon is accordingly 18m deep. Very nice there.
The height lines on osm maps and on vector maps from Locus store based on osm doesn't show any hillsides inside the canyon. Means, all the lines parallel to the the creek are missed. Due to the heigth below 20m there are no information about altitude differences.
Example: if i use "add / meaure route" and across the creek or moving the center cross over the creek and over the hillside i get 5m height difference only.
If i choose the path by feet up and downstairs i get 16m downhill and 16m uphill as real numbers (not in Locus). Doing this recurrently i get a lot of height meters but not noticed by Locus.
This problem seems bigger to me than don't know the exact altitude of the Schwarzachklamm yet. In landscapes with rippled surfaces and altitude differences <20m like in average mountain or foreland of the alps there are no exact values on maps and in SRTM files also.
How to get the information about the exact altitude?
Any hints?
Christian
Hello Christian,
It seems that you know the SRTM data. Locus and probably OpenCycleMap use similar data for contour lines. Locus use SRTM3 dataset which you can imagine as grid of points on Earth surface. This grid has resolution approximately 90 meters. Narrow canyon may not influence the altitude or contour lines because simple there are no data from the canyon. I have to also notice that accuracy of SRTM data in elevation is about 5 - 10 meters. This is another reason why canyon may not be "visible" in the data.
SRTM can not detect such small changes in earth surface.
Thank you Petr for explanation.SRTM3 is th crux.
USGS has released (http://www2.jpl.nasa.gov/srtm/) SRTM1 for public in 09/2014. Is this supported by Locus? If so i will try to download via earthexplorer...
Yes, Locus is able to read the SRTM1 hgt files. Put them into folder Locus/data/SRTM as standartd SRTM3 files. And thank you for information about release SRTM1 for rest of the world - I didn't know it. Honestly not sure if we use it because SRTM1 files have 10x bigger size then SRTM3 files. We also had some troubles with contour lines on the border of coverage of SRTM3 and SRTM1 areas. Hovewer good to know. Thank you.
Downloading SRTM files from USGS is a mess :(
ok, there are no .hgt files. Only .bil, .blw, .hdr, .prj in BIL-files.
Additional there are .dt2 as DTED and GEOTIFF.
Wich files are needed?
You need the *.hgt files but honestly we didn't download them from NASA or USGS. Please see http://www.viewfinderpanoramas.org/dem3.html where is possible to download *.hgt file in packages for bigger areas. But it seems that new released SRTM1 files aren't available here. So sorry I can't give you any clue where or how to download new SRTM1 data. But if you find out how to download them ..I'd like to know it :)
:(
Thanx.
Site for downloading SRTM v3 is here:
https://lpdaac.usgs.gov/data_access/data_pool/
Direct links to SRTM1 look like this:
http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL1.003/2000.02.11/N49E020.SRTMGL1.hgt.zip
And to SRTM3:
http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL3.003/2000.02.11//N49E020.SRTMGL3.hgt.zip
FYI server shows following warning at directory listing:
U.S. GOVERNMENT COMPUTER
This US Government computer is for authorized users only. By accessing this
system you are consenting to complete monitoring with no expectation of privacy.
Unauthorized access or use may subject you to disciplinary action and criminal
prosecution.
Quote from: popej on February 12, 2015, 16:48:14link to SRTM1
http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL1.003/2000.02.11
hmm but all files are from 2012
(http://s13.postimg.org/vsmprerjn/2015_02_12_195557.jpg) (http://postimg.org/image/vsmprerjn/)
just creating SRTM1 .hgt files :)
New files quite huge. How to change the path to store the SRTM data on external SD? I didn't find anything in config file.
Will write a small tutorial after testing...
Try
Settings->Misc->default dirs
btw.
All testings already done before.
...years ago :)
Thanx. Never thought that settings available in UI. Great job menion!
What did you test? public SRTM1 data?
ok, SRTM1 works in Locus.
Quote from: Christian on February 12, 2015, 23:16:27
What did you test? public SRTM1 data?
Sure, that stuff is not new :)
small tutorial
how to get SRTM1 data as .hgt files working in Locus
: go to www.http://earthexplorer.usgs.gov/ (http://www.http://earthexplorer.usgs.gov/) (download from DLR not working 'cause download link is broken)
: enable cookies in your browser
: register as user, tell them all the things they want to know (color of underwear, last sex...)
: choose Digital elevation model -> SRTM1
: choose area where you want to download elevation files by polygon tool from map or use shape file if available
: follow process, stay calm
: bulk download doesn't work for me (and you have to install a bulk downloader at first and download doesn't work either)
: download each file in BIL-format manually: *_bil.zip (5MB each)
: unzip all *_bil.zip in one folder (one zip contains 5 files)
: go to http://www.mediafire.com/download/vuby9jvdk8r7drm/BILxSRTM.zip (http://www.mediafire.com/download/vuby9jvdk8r7drm/BILxSRTM.zip)
: download zip file and unzip
: start BILxSRTM.exe
: choose folder with unzipped .bil files
: choose folder where hgt files should be stored
: press start and create hgt files. New hgt files have 25,7MB each. If you fear to run out of storage in your phone:
: create new folder on externalSDcard
: copy hgt files to external SD card of your phone
: set new path to SRTM files in Locus settings-> misc-> Locus/srtm
: restart Locus
enjoy new elevation values.
First test:
works smoothly. Got more meters uphill and downhill in statistics of an existing track.
Quote from: gynta on February 12, 2015, 23:20:08
Quote from: Christian on February 12, 2015, 23:16:27
What did you test? public SRTM1 data?
Sure, that stuff is not new :)
SRTM1 data were released September 2014 for public.
???
Test with high resolution hgt file:
http://forum.locusmap.eu/index.php?topic=2936.msg19528#msg19528
(http://s13.postimg.org/60ko2l8tv/2013_03_15_195130.jpg) (http://postimg.org/image/60ko2l8tv/)
Hmmm interesting news and nice work! Can you please tell me how big the difference is between the new and the old version in say 10, 50 kms?
Quote from: gynta on February 13, 2015, 00:19:09
Test with high resolution hgt file:
http://forum.locusmap.eu/index.php?topic=2936.msg19528#msg19528
You are always one step ahead ;)
Quote from: Christian on February 12, 2015, 23:27:44
small tutorial how to get SRTM1 data as .hgt files working in Locus
and what's wrong with...
Quote from: popej on February 12, 2015, 16:48:14
Direct links to SRTM1 look like this...
?
Second impression of SRTM 1:
: SRTM1 data don't solve my problem with small canyon :( I get 7m uphill instead of 5m before, but it should be at least 16m
: Guess, hillshading with SRTM1 data needs more power than with SRTM3 especially when zooming in / out many times. Menion & Petr, did you test it and can you confirm more power?
Thanx Gynta for sniffing indexes ;) Looks like updated data after Sept / 2014.
It's more on menion...anyway SRTM1 hgt file contains 9 times more data then SRTM3 file.For this reason hill shading with SRTM1 files is more time and power consuming.
If there will be interest, I may spend some time and measure it more precisely, but there should be no reason for higher CPU and memory requirements, no matter how big HGT files are.
No, thanx for offering. Its not worth to spend some time on it. Having 9 times more data it must be 9 times more computation...
I noticed a little delay when zooming in /out. So I wanted to ask for experience only.
amount of data should make no difference as I wrote. Locus divide every tile (256x256 px) on a small grid and compute altitude values from HGT file for every single point in this small grid.
But this value is computed just from four nearest altitude values from file. And obtain of these four values is independent on file size as Locus directly skip to exact place where required value is in file (I'm now anyway not 100% sure that size of file has no influence, but should not).
Quote from: menion on February 14, 2015, 23:27:12
amount of data should make no difference as I wrote. Locus divide every tile (256x256 px) on a small grid and compute altitude values from HGT file for every single point in this small grid.
But this value is computed just from four nearest altitude values from file. And obtain of these four values is independent on file size as Locus directly skip to exact place where required value is in file (I'm now anyway not 100% sure that size of file has no influence, but should not).
Menion, I can't understand your description completely but does it really describe the algorithm for hill-shading?
yes :). Nevermind ...