Precise SRTM .hgt file handling
Answered
How is Locus Handling the .hgt Files ?
I mean, the SRTM format is same as BIL. Difference: just with defined pixel rows and clumns.
Is Locus able to handle a bigger .hgt file ? Do Locus calculate the pixel-spacing or just use one of the 2 normal possible ?
I want to use a much more detailled height model ! (Lidar Data with 50cm Spacing or 1 m)
Good day Markus,
if you have data prepared, best is to give it a try. I think it should work (and if not, create a bug report and attach one file for test). Only thing I'm little worried is fact, that app load necessary HGT files directly into memory for a lot faster work. 1m files will be probably really huge so there will be need for some automatic optimization and disabling this system. Anyway give it a try and you will see, I've personally never tried/used such huge HGT files.
Ok, Thanks for fast Answering
I use GlobalMapper to export my Data to the .bil Format. (Motorola BigEndian Byte-Order) rename it to .hgt
Delete the corresponding File that Locus downloaded and replace it with my "new" one.
When I export my Data as .hgt -File (SRTM 1") i get it working but with the standard resolution. And it seems also to be very close to .bil format. (I am just able to export as .bil in custom Resolution)
I think i should keep the square Area of the Data so that Locus maybe is able to use it. (I don´t know how Locus parses the Data).
So I give it a try the next Days.
I'm not sure if simple rename will work, you will see. I remember I worked with bil format some time ago, but it's direct internal support was removed few years ago.
App should anyway work with all HGT files, no matter how precise they are.
It is working when i export as .bil file with same Resolution than 1 arc second. (so export as .bil and just rename works)
So it seems now that locus is just using one of the standard resolutions for srtm-files and can´t handle other resolutions.
Maybe if we say all files contain Data for 1 square arc second tiles. So we are able to calculate the point-density.
And locus load just a maximum count of opints to working memory (ram) ? to save memory.
My task is to use it in a mountain Rescue Team, and when we go to unknown terrain sometimes it helps to see in high detailled height model where are holes or steep rocks. or get back height values.
OK i can load a Hillshade-Map with high detailled Raster hillshade. but then i don´t have the right height data.
Good day Markus,
I'm checking implementation of this feature and for me it should work, no matter how big are HGT files.
May you please share one file with me for test? Thank you.
OK, yesterday i tried again. I exported as 0,1" grided Data. But Locus can´t work with it well.
If i Export as 1" grided Data then it works fine. (same method of Export as .bil, then rename to .hgt) I try to Attach a File with 0,5" Resolution. I hope the Size is not too big.
Are you sure Locus don´t just decide if Data is 1" or 3" ? Because in .hgt Files there is just a Grided Data, not the coordinates for each point. So Locus have to know how the Resolution of the Data is. But Locus also don´t work with Header Files... so... How do Locus find out the Resolution ?
For me Locus is really the best mapping app on Android, so i hope my task is solveable. Now I try to generate 0.5" grided Data and attach. I don´t calculated but i think the Filesize is around 200MB for a 1 degree cell. I try it with my Region N47E009.
Good day Markus,
our help desk most probably refuses upload of such huge file, so please use any Google Drive or similar service, thanks.
And app detects resolution of HGT file thanks to filesize. Size has to be always the same for the same resolutions.
ok, i found out where the Mistake was..
My Data is in Meter accuracy, so exported them to grid resolutions for example: i tried 3m to 3m grid resolution.
But Locus Needs a binary dividable raster resolution of 1 arc Second. So possible is: 0.5 arc second grid spacing, 0.25" spacing, 0.125" spacing, 0.0625, ..., so ist not possible to make exactly 10m Resolution, but something close to.
So now it is working fine. thanks. I get really precise heights and also a Hillshade. (I see little rivers and also roads on Hillshade)
My next Task is to find a Software that generates better .bil data. (=.hgt data with Motorola Byte Order)Because Global-Mapper start produce Little stepps when use resolutions finer than 0.25 arc seconds as Export.
Or Maybe i let this data at a Resolution of 0.125" (close to 3m Resolution) and use a Map-Overlay (Multiplied) with Grayscale shaded Image of Hillshade. (I also use this on my Garmin Device).
You found a problem with your generated files: perfect!
I'm glad it works for you now. If there will be something I may help with, feel free to ask.
Hello
Now i have a question. When i plan a new Route manually (line of sight). And then look at the routes Height- Graph. Locus do not "interpolate" along the Route-Line, while viewing the graph ? Locus just usrs heights of the route points ?
Is it possible somehow to get a path profile ?
I think Garmin is doing it like: when you are in path-profile window, they "interactive" take tighter height points "below" the line of sight, while you zoom in.
Ok, every 100m a point, so Locus don't show meters deep stream ways, when not hit by the 100m raster. Is there possibility to improofe this ?
Understand. Quite a specific task, but let's try it ...
Thanks for sharing of your shaded SQLite map and HGT file. Both downloaded and correctly displayed in app. And now what to do with it :).
Firstly, a quick test in route planner with visible SQLite map and drawn short profile show over some huge terrain changes show no problem to me.
The application uses bicubic interpolation from 16 interpolated points around the required location. In this interpolation is most probably not an issue because otherwise, it will be clearly visible. So the problem really may be in some shift of computed row and column indexes of elevation values.
The whole algorithm is little complex and because if there is an issue, it is really tiny, I cannot invest a day to finding exact reason of possible small shift of interpolated elevations, sorry to say it. We anyway planned to optimize shading in the app in the near future, so I'll keep this in my mind! Thanks for understanding.
Thanks, for me Locus is a really good app. And maybe I manage somehow to shift my .hgt Data some Meters.
I see the Shift best when i plan a manual route, open Route height profile and tap on the Top of a falling Edge, then i see the cursor shifted some meters away from the cliff. Also when i plan a auto-route along a street. (The Street is exactly drawed to the lidar data in openstreetmap). Or by just gwtting heights from cursor position near a cliff.
Hello,
I tried what you describe: "plan a manual route, open Route height profile and tap on the Top of a falling Edge". I tried this maybe on five places and on all it looks correctly. Give me please some start > end coordinates of line, where this will be clearly visible, thanks.
Hello
I work with disabled Hillshade but enabled Overlay "ESG-Hillshade" multiplied mode. (100% non Transparent).As Map I use "Freizeitkarte ALPS+East" or also LoMaps-Austria.
I Start a Manual Route...
Start at Position : N 47°18.209' ; E 009°40.001'
End at Position: N47°18.172' ; E 009°40.022'
Then I tap on the Height-Profile Icon (bottom-right Corner).I tap on the middle of the first flat Region above bottom. (middle of the "Road")
The Cursor on the Map is then shifted. (because the Height-data are shifted to top-left. (About 5.5m to Top and 3m to Left(nearby 0.125 arc-Seconds = the Resolution of my Height-Data = one Pixel)
Or I see it better when I enable the Display of Height-Values at Cursor-Position. And move to an Edge, then the Values start rise at shifted Position.
Now I shifted just my .hgt Data (my Hillshade-Map "ESG-Hillshade" is the same as bevore).Its much better now. For the shifting i had to download the N47E008 Tile and the N48E009 Tile and shift them all. Then cut the Data to the exact Window of the original N47E009. (so I got additional Data at Top and Left but cutted Data from Right and Bottom = shifted Height-Data to Bottom-Right because Locus takes the new Data as N47E009)
I uploaded the New Data to my Google-Drive.
https://drive.google.com/file/d/1QYYcqnRP55ywqjw8W_X2IvbamoTSiXcc/view?usp=sharing
Thanks Markus for the precise description ....
So after maybe two hours of testing (and half of hour of sleep after falling asleep during thinking :) ), I have this result for your two coordinates.
Better right? :). Seems to match your generated map a lot better.
Ah back, sorry. This my "fix" was incorrect and instead, it created another issue.
We here compare the result of Locus Map vs result of some program you use and I tried to "fix" Locus Map to match data from you. Is there any other option how to test, which program gives correct results? Because I'm just unable to find a mistake in my old algorithm. All seems to match!
Hm, yes. There is a projection problem. Its not just a shift. I exported with exactly x and y square 0.125 arcsecond resolution. And a wgs84 projection. I try to check this in my projection header files. The Thing is: when i open both Data in the professional GIS Sodtware it fits cm exact. (Hillshade and .hgt) But Difference is: my GIS Software uses the additional header files. And locus calculate from Filesize
So i check what is inside the additional Files
Ok, found a problem in my Data. I used the bounding-box from the original 1" .hgt file, to cut my Data to. But with my higher Resolution, the box don't hit the right points. So my .hgt had additional data, and locus did a stretch or push
Solution was: to cut Data to exact N47 and N48...
Oki ... so at least I've confirmed that my algorithm is correct.
Menion
Thanks for the Work on Locus. And sorry. My GIS-Software did open the .hgt-File always with the additional Projection files. So there it looked perfect matched. And my Idea to use the Bounding-Box from an original 1" .hgt File to cut my Data, was a mistake.
Hi Markus
I'm also working in the mountains. I've tried to export to BIL in globalmapper, but cant get it to work. It produces a file of size 1kb. No problem exporting directly to the hgt format at 1". And results in that resolution based on DEM from norwegian mapping authority is better than the autodownloaded 3".
But do you have any idea why i cant export correctly in BIL (tried 0.25 0.5 and 1")?
Maybe you have developed your recipe further? Please share :)
Not sure if it helps, but here are the Norwegian LIDAR data in different formats, compiled and provided by Sonny: https://data.opendataportal.at/dataset/dtm-norway
You can download them separately and move them to the right place in the Locus folder structure, or even leave them in separate folder and adapt the MISC setting in Locus for SRTM.
Cheers
Michael
And you Try to use the 1m DTM Data of Norway ? Then it would sure give super Results. At moment i am Downloading Data from Norwey in 1m ground Resolution. Cool that in Norway such high resolution Data is also available.
Høydedata (hoydedata.no)
https://hoydedata.no/LaserInnsyn/
Yes thats the data im using. Until now its only lower parts that is in that resolution, plus some mountain/glacier areas. In a year or two the whole country should be in 1m resolution. Its very cool. I've been using the LIDAR clouds with vegetation to make ski maps of the forest. The big pine trees have a very clear signature....
I did not have anymore time this weekend, but i will try again the next couple of days. For now i'm just trying to get it to work - the whole conversion thing.
Hillshade - i grew up without it, but on my maps with high res slope-steepnes shading in green yellow red brown and black contours the shading really helps getting the 3d feeling. And i'm really excited about how it will work for skiing with the 1m resolution. Maybe its to much info. When it comes to slope-steepnes shading i find a 4m horisontal resolution the best.
Would be great with a video or some other step my step recipe. I tried follw the one you gave, but must have done something wrong along the road.... For now im just trying with the 10m resolution...
Hello,
In France, since 1st of January, the IGN DEM at 5m resolution is available freely. And the DEM at 1m will be available in march.
Not a problem to use it in a lot of applications (possible to do some conversions or transformations with QGIS).
But, how to use it in Locus Map ? I understood that Locus accept only HGT files with 1" resolution, is it true ?
Best regards,
Replies have been locked on this page!