This object is in archive! 

Precise SRTM .hgt file handling

Markus shared this question 5 years ago
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)

Replies (39)

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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 ?

photo
1

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.

photo
1

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.

photo
1

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).

photo
1

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.

photo
1

And yes... I didn't use the right Resolution.

After you told me, that Locus uses the File-Size to "calculate" the Resolution, it was all clear. I have to use square resolutions in divided parts of 1arc second. Thank you much.

photo
1

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.

photo
1

Hello Markus,

when you enable manual drawing that Locus should interpolate between the start/end points of the line for usage in Route planner. Usually, it should generate points every 100m. You see at the bottom chart only straight line? You may even slide up the bottom chart and then move with start/end point to see changes in the chart immediately! let me know if this works for you.

photo
1

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 ?

photo
1

Understand. Quite a specific task, but let's try it ...

photo
1

OK, I tested it. And YES, much better. I tested it by making a manual Route uphill out of a quarry. Let me describe: its a hole where are roads around in circle and Hill-upwards in steps.

And now i see the Steps of the Roads like in a real Cut of the Terrain. Just because of the limitation to 5m i sometimes don´t see one of the road-steps. (I need to play around with the 2nd Route point so that the Interpolation hits also this road)

So is there a reason why the minimum Value is limited to 5 m ?

I think its an Option, because allways changeable back to 5m or 100m.


If you give me the option to go down to 1 m interpolation, I try to make even better height Model of my Region.

At the moment i have about 3m stepping model, OK, locus is a little bit slower in panning around (when Hillshade is turned on), but i also switch off Hillshading sometimes, because i use LoMaps overlayed by a Grayscale-Hillshade-Map (more steep = more dark). As Overlay Method I use Multiply or Darken. So I normally don´t need the Hillshade Option in my Region. And Locus is really fast in overlaying this 2 maps. Panning and zooming is so REALLY FAST.

I need the .hgt data just for getting good Profiles and for measuring Height differences exactly. My Basis-Data is normally 30 cm exact in height. (75% of all the points, most of other points are 50cm exact)

At all now Locus is really close to be GREAT for my Task. Thank you really much for this Tool.

Because I want to show Friends in the Mountain-Rescue-Team what Great Maps are possible today, I have sometimes special tasks. But now most of them are done great.

(Now we see where to get out best, where is a possible route in Offroad-Terrain,...)

photo
1

Hello Markus,

glad we have some progress. I choose 5 meters limit as the compromise and also some kind of security mechanism. The too low number may cause slow-down (in real-time interpolation when you move with one line point in Route planner), so I wanted to prevent setting of too low number. Anyway ok, let's try it to next version with the 1m option.

I'm surprised to read about elevation data with such huge accuracy mainly in mountains. Anyway, I'm always glad to read that Locus Map seems to be a helpful companion in useful professions.

photo
1

Hello

OK, Now i get really realistic profiles. I attached some Screenshots. And its also very good to get fast access to switch overlay on or off, to switch Hillshade on and off,... Yes Locus is really Good for my tasks.

Hm... Just some little thing is...

Ok, when there is a Road and i plan an automatically Route with Walking-Profile, i get a Height-Profile and its also the same when i open the saved route-details and go to diagramm (profile)

BUT not when i save my mannually planned route. When go to details and profile, i get just the profile of my manally set route Points.

My Idea was first: if the 1m thing works well... why don´t we make it one step ahead.. and make the interpolation density dependable on the x-Axis zoom of the Height-Profile screen. (so interactively get the data from background .hgt data).

So that we get really more detailled when zooming in the x-axis. and less detailled when zooming out. So the problems with too much points is also solved. Maybe change the new option in Expert-Mode-Settings to a Factor-Variable, so with this factor we can choose the relation between x-Axis and interpolation-density.

photo
1

Why is it working well in a automatically calculatet Route-Profile ?

But not in manually created.

Maybe you can helpe me with this also.

photo
1

Hi Markus,

in case of the automatically computed route, the route itself is made from many trackpoints which are then also visible on the chart. So there is no interpolation between points. In case of manually draw route, in the final route are really saved only manually defined shaping points and interpolation we talked about before, is lost.

I had a similar request on old forum a few days ago, related to applying correct line style also to these manually drawn lines, which is the exact same problem.

Saving manually draw segments interpolated with 1 m is little overkill for huge lines. Understand your use case and agree that what you see in the route planner should be visible in saved track as well. I'm just not sure how to simply technically do it. Because it is more complicated to do and because it currently has a low priority, I'm sorry for now, but can't help here now.

photo
1

ok, I think when going to route-details and to profile Page, there decide if its a Route or a recorded Track. (or in other words, if the route have recorded height-data or not). If its a Route without recorded height Data, then lets say get 800 height-Points of the whole "Route" and display it in the Diagramm. If you zoom in: then also take 800points but just of the visible Part of the Route (visible on Diagram x-Axis). So we get more detailled while zooming in. And Just if you export a Route to a Track, you can decide if you want to fill height data in or let it without height data. So its close to the thing when you analyze a segment of the Route. (Shift Start and End point along the Route while Zooming and Panning on the Height-Profile)

Just my ideas to this.

photo
1

I think, the easiest way at Moment: Save all the interpolated Points. (Standard-Setting is to 100m, so no Problem)

Because: if i record a Track with Settings to 1m or 1s i also get much Points. And as you told, when planning a Route by any Kind of automatic Route-Calculation, locus also use many Points (all Points of the Road-Line ?).

I think it is no Problem to save also, for manually created routes, all interpolated Points for the Height-Profile. (Users can Always set the Interpolation-Step back to 100m or so)

photo
1

One Other Question:

Can you add also a Parameter for "Heicht data multiplicator" as Standard set to 1.

My Problem: The height data Format is in 16-Bit integer values. So without making a Little "trick" my Software is just able to create Height-Grid in steps of 1m.

But, now i Exported my Data in "dm" Units. so i get 1000m instead of 100.0 m.

So Route-Calculated-Time is wrang and also other Parameters.

But if you add a factor to height-Data, then it will be perfect.

Thanks

Greets from Austria

photo
1

Good day Markus,

give a try next beta version, it will be improved little bit and interpolated points will be saved in final generated route. We will see how this will work.

About your second request: sorry, but such special one-user options will only overcomplicate UI of app. Thanks for understanding.

photo
1

ok, sure i understand. hm, i think its just a multiplication-facror of the height-data. if set to 1, there is not much cpu-extra load. And opens the possibility to use smooth height-data for everyone. In near future there will be available a worldwide high-precision height model.... ok, your argument for over-complication.

So thanks anyway. I can use 2 Files. 1 with Meters height data. (for standard use and for better time-calculation in routes) And one with deci-meter height-Values. (really smoothe display and smoothe %Uphill/%Downhill Graph)

photo
1

Hello Menion

Thanks for adding this Parameter.

When I make a Manual-Route (Line of Sight) and i make shorter Route-Point distances than 100m, I don´t get the interpolated Height-Profile of this section.

But this is really neccessary, because when i plan a Manual Route i have often route-Point distances smaller than 100m, (And so no Interpolation between them)

So in the Software there is somewhere an additional Parameter which is fixed to 100m. (Minimum route Point distance for Interpolation)

Maybe you can set this Parameter equal to the "new" Parameter in Expert-Mode. (Interpolation-step)Reason: I think this can be same than route-Interpolation-step, because if someone wants tighter Interpolation steps, then the Minimum route-Point-distance also should be smaller.

At the Moment i Always have to make longer route Segments than 100m to get detailled Height-Profile. But in Terrain this is unusable. (I want to draw my Walking way down somewhere and get the height-Profile detailled)

Thanks

photo
1

Hello Markus,

you are correct. Hard-coded 100m parameter found. Will be fixed in next version 3.37.1, thanks.

photo
1

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.

photo
1

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.

photo
1

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.

photo
1

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

photo
1

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.

/969c29a2b92cc179624a51034d5d10ac

Better right? :). Seems to match your generated map a lot better.

photo
1

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!

photo
1

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

photo
2

So i check what is inside the additional Files

photo
1

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...

photo
1

Oki ... so at least I've confirmed that my algorithm is correct.

Menion

photo
1

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.

photo
1

Hello

Yes it works perfect. so you have Meshed your data to a TIN? Then first thing is to export as .gmg file (greed) with cm as height units. And then you have to have also surrounding Data loaded in GlobalMapper. It can be tiles of SRTM. So for ecample, if you want to create a new N47E009 tile, then load your High resolution Data (can be any Area) inside N47E009. Then Load SRTM data of N47E009, N47E0010, N47E008, N46E008, N46E009, N46E0010. And also the 3 N48 tiles.


(Your High-Resolution Data Topmost)

Then click on File Export as Greeded Data, Select BIL.

Set your wished Resolution as Binary divided. So possible is 0,5" , 0,25" , 0.0125" , ... and so on.

AND exactly export a Region of N47 to N48, and E009 to E0010, (Exaxtly the Tile-Size of N47E009.) If posdible select Bicubic Interpolation.

photo
1

I think you have to set the right projection first in Global Mapper. (Bevore u export to BIL, use the standard .hgt projection) If i remember right its Standard WGS84.


After this Process you (just) have high resolution Height-Data. So Locus can Show you the Height value and Hillshade.


But... for me much more important is to export the GlobalMapper Greeded Data to a Raster Map in .mbtiles format. Use in Globalmapper as Hillshade: Slope Shading. Set the Colors for 1° steepness to White and the Color for 89° steepness to a customized Gray-Tone. So that you get a Graytone Hillshade of your Height-Model.


Again use surrounding Height-Model to fill up missing Data to a Rectangle of any Size. Set your Projection in Globalmapper to the google Projection which is Standard for MBtiles format. EPSG:????

Then Export your High-Resolution Hillshade to the MBTiles Raster Map. (its like making a Screenshot of your actual Hillshade wiht actual Hillshade Settings)


After this you should have a perfect Raster Hillshade Map, which you can Overlay in Locus (Multiply) to each other selected Map. So Also to any OpenStreetMap.


LocusMap is much faster in overlaying a Raster Map (Multiply) than to produce a Hillshade.


This works perfectly if you have at least 5m resolution Height Data of your Region.

photo
1

THX - working on it. Got some weird results, but will work more :)

photo
1

i try to make a better help. Because i did asnswer without going to check. I plan to upload my created Files. And maybe i manage to make a Video about it.

photo
1

Because i worked about 2 Month till i had the right Solution.

photo
1

How dense is your Data. I mean the ground Resolution ?

In my Region i got Data with 1m and 0.5 meter ground resolution.. (points with Height values)

I did use the height Data without Trees (ground Points). This Data is calculated so that i see 1m thin walking ways also in forested Regions.

photo
1

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 :)

photo
1

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

photo
1

Yes, This Data provided by Sonny i use to Fill up surrounding to full Tiles. (Because Locus needs Fully filled Tiles)

But the data i use is much more dense. (1m or 0.5 m ground resolution)

1. Then i export my high density meshed model with cm as Height Unit. (no other resampling, bevore they have been in meters for height units) --> this results in much more Smooth Surface after export to .bil format.

2. I load Sonny´s Data for all Surroundings. AND also export them to "Global-Mapper Greed" with: cm height resolution. (can also be axported as one Tile or in Tiles)

3. Then i unload all Data and load the newly generated meshed Models. (My hires data and the Surroundings)

4. I then change the Workspace Projection to EPSG:4326 (=regular for .hgt files)

5. Then export whole Workspace to a .bil elevation data. There choose:

Elevation-Grid 2 Bytes (Signed)

Sample Spacing: 3.4722222222e-5 arc degree (= 0.125 arc Seconds)

Always generate Square Pixels

Resqampling: Bicubic interpolation

Vertical Units: Meters

Interpolate to fill small Gaps in Data

Motorola Byteorder !!!!

AND: as Export Bounds choose exactly a full Cell. (for example: to generate N47E009 export Bounds:

North: 48 ; West: 9

Sauth: 47 ; East: 10


Then you should get a .bil with Motorola Byteorder. This File can be renamed to N47E009.hgt and copied to SRTM Data in Locus folder.

This is just the 1st generated File. Now lets generate the more necessary Raster-Map from your Data....

Therefore let all data Loaded in Global Mapper and set Workspace-Projection to: EPSG 3857

Set the Hillshading to "Slope Shading" with White-Color at 1° and a custom made Gray-Tone at 89°

Then we are ready to export to .mbtiles Raster format. (Size of export Boundings as you wish)

photo
1

upps did not see this part. Thx Michael and Markus. More stuff to look into - great :)

photo
1

The hgt are working now. I did it like this:


Opened my geotiffs from the norwegian mapping authority in globel mapper. Reprojected ti Geographical Lat/Long in the configere menu under tools. Exported directly from there to BIL with the settings you recommended Markus. Works fine thx. Now on to the hill-shading

photo
1

If i did so, i got "Steppy results". I did therefore first export to "cm" elevation units. (as global mapper Grid).

Then work with the "new" generated data and set in the Layer Options of the "new" File to Bicubic interpolation.

Then export to .bil File as i described.

This Step with setting the Bicubic Interpolation to Layer options to the Files is more significant if you export to .mbtiles Format, because its like making a Screenshot.

Did you also download the National Datasets ? If you klick on Download and select the Register ("National datasets") i find rich 1m DTM files. (DTM1 the 1m resolution).

And for filling up some missing spots i downloaded (DTM10, the 10m resolution of whole)

photo
1

Yes, i also got stepped results, but only when trying to make the hillshade in global mapper, Not in the terrain model itself. So i tried to make the hillshade in golden Surfer, which seems to work better. I'm still not sure if i want this kind of hillshade, but i will try to evaluate it in very zoomed in cases...


My main aim is the elevation data to be precise, because , as i understand Menion, the next version of Locus will also give us the inclination between two points or between position and cursor. And to use that for avalanche assessment it is crucial that the elevation date is precise enough...


My maps (home made) allready are loaded with slope color shading to mark any terrain between 20 and 90 degress steepnes.


Tried to attach a file - dunno if its working. But there you can see the border between the 1m and 10m resolution as a brown line (because this is where the 1m model ands and "drops down to 0 meters). Brown is the color shading for steeper than 55...

Link to map: https://drive.google.com/file/d/1g2-bcayNA4DzB-X3sNBeKcWGso5keV2z/view?usp=sharing

photo
1

Its funny though. Norwegian mapping really kept their data very pricy a long time after the EU had decided they should be free. But after 10 years or mor with legal threats the Mapping Authority caved in, but then announced it as a voulantary gift to the people. But mapp quality and availability have been booming since data was freed, and it shows out to be of huge public benefit to free data like that. And in a year or two we will have terrain model of every tree and every stone og drop or whatever feature that is either part off the terrain or on the terrain

photo
1

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/

photo
1

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.

photo
1

I did make the Hillshade with Slope-Shading because if i Shade in any direction, i get "Shadows" in regions where are not so steep. And i can´t see some Details anymore.

With Slope-Shading in Graytones from White = 1° to Graytone (82 away from Black) i get a Hillshade which is just Dark in Steep Areas, and exactly this i want to have. (Where is it difficult to get down... )

I did choose 0.125 Arc Seconds as Resolution because its close to 3m Ground resolution. Thats enough for Elevation and Hillshade Data. (Locus is handling it good)

I just use this for what it is, Elevation-Data at cursor Position. (And sometimes as additionally Hillshade)

And that i get Profiles of line of Sight. (Terrain-Cut)

But if u try to Hillshade the 1m Data in Global-Mapper with Slope-Shading (1° White, 89° Dark-Gray),

and zoom in to where are ways in forested region, or Waterways going below some ways, you will find out, that you see really rich details of Terrain. (You can measure how wide a Road is, to see if its driveable by a car)

And exactly this view i wanted to get on LocusMap, and i got sucess with generating 0.5m/Pixel Raster Maps.

(yes in meters because Projection for .mbtiles is the (google) pseudo mercator) 0.5m/Pixel keeps nearby all details of 1m Height data.

And sure, the Trick is to overlay this Data to a LoMap (osm-Map) by Multiplication in LocusMap. (You can also try to Overlay Multiplicate "OpenStreepMap (basic)" in GlobalMapper, (you will get a good view of Map + Hillshade)

Greets from Austria (And yes i want to travel to Norway in some years... hopefully with really good Maps :-) )

photo
1

I wil lwork with this ;:) thx. And welcome to Norway anytime..

photo
1

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...

photo
1

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,

photo
1

Hi Bernard


Its possible to use higher res in hgt files, as long as they are 0.5", 0.25", 0.125" and so on.


Its all in the discussion here, somehow.


We tried some different mixes of software and approaches, and it would be nice to see if we could get it working in qgis, but i'm just in the beginning of getting familiar with qgis,....

photo
1

Hi guys,

nice discussion. Just from my point of view: Locus Map does not force HGT files to be in 3601x3601 grid. Grid is determined on the fly from the file size. If some files won't work, just send me it for the test. I'll analyze and wrote back where is a problem.

Menion

photo
1

Hello,

I've tried to make some highres DEM "pseudo"HGT : I discovered that in fact, Locus needs only square grid, no matter the size. Mine is 16423x16423 (i.e. about 0.2192"), and it works fine ! Not necessary to be exactly 0.5, 0.25, ...

I used QGIS to generate a BIL file (Int16 little indian BIL, QGOS can't write directly big endian HGT for that size), and the Unix "dd conv=swab" command for byte swapping.

Works great !

Bernard

photo
1

Yes, square grid is a key :).

Menion

photo
1

Yes, just export Square in the right Projection for SRTM Data. And full cells of exactly 1 arc second.

photo
1

Thx. Will try that in Qgis :)

Unix "dd conv=swab" - i need to look into, But i have a linux server i might do that on. Totally noob when it comes to byte things..

photo
1

If you have a BIL in INT16 big endian, the exact command is like that : "dd conv=swab < your-dem.bil > NxxEyyy.hgt".

For France, the hires DEM are in format ASC, and Lambert93 projection. So, I'm using QGIS to merge the ASC for a grid, reproject in WGS84, extract the exact square grid and generate the BIL.

The most difficult part is that a HGT file can't be recalibrate. So it is necessary to be very precise when extracting the grid. Recently, Sonny generates new HGT for France, using these IGN data (standard 1" HGT), but most of them are not correctly aligned, so, cells are shifted by one or two... it means between 20m and 40m shifted (E or NE in general). And precise data, but not correctly calibrated... not so useful...

Bernard

photo
1

Hi,

why do you think my new DTMs of France are shifted? Can you provide some examples with screenshots. If you want, you can directly contact my by e-mail to prove your statement.

photo
1

I didnt check your data. Just what i did wrang one Time is: To clip Export-Bounds by a Bounding-Box of another resolution .hgt File. (I got a little shifted Data).


What i did Learn is, to always define the Coordinates for Export. (to exactly straight values)

photo
1

Hi,

Here are some examples :

cc2f5abcb301b2a4d617ec7fe55e5020

40c063d0d8fd529750b0f50e46c4d356


ebb62c43b5a8b0b049a66686205520ff


There is no problem with your 20mx20m TIF files.

Bernard

photo
2

I've checked the correctness of reprojection and resampling of my new HGT-DTMs of Fracnce. And to be short: They are absolutely ok, Reprojetion as well as Resampling has been done correct. There's no systemtic shift of the new HGT files compared to the source data of IGN France.


Since Bernard Perrot accused me that my DTMs are "not correctly calibrated" and shifted, without contacting myself before to clear his accuse, I want to publicly falsify his statement. Usually these explanations are too sophisticated for the Locus forum and I dind't wanted to defend the correctness of my DTMs in public, but anyway, here we go:


1)

If you want to juge the positional correctness of DTMs you have to look for a very good reference to compare with. This can be good positioned Orthophotos where we can identify appropriate objects to compare with (summit cross, streets, river banks etc.), or survey points with surveyed coordinates and altitude.


In general it's better to use a region in the flatlands and its objects (streets, Riverbanks,..) to compare with, than a steep mountain ridge - as provided by Bernard in his examples. Reasons: Orthophots of steep ridges are very hard to rectify correctly for the organisations providing these Orthophotos. Not each peak on the Orthophoto is exactly where the real coordinates of the peak is. I don't want to go into detail of the reason, you can ask professionals who will explain it to you.


Further: Usually LiDAR Source data is finer, more accurate in the lowlands than in steep mountainous regions, especially if the mountains are coated with the snows of glaciers. This fact is also true for IGN 5m. So if you want to prove the correct position of a DTM - better use something in the lowlands!


And of course use the correct position of the summit as reference ;-) Look at Screenshot 1. Bernard's "summit" of Puy Mary is about 50 m west of the real summit. The real summit is marked by an IGN survey point Nr. "1510201 - A" (elevation = 1784.53m). Also watch the blue "lookout" icon just above the survey point which is a optical reference for the summit in the following screenshots.

ad3d5b18446a6b299172fa8296a9d2e0


2)

Check the correct postion of the source data.

That means: did I use the correct projection to import the source data? (for IGN 5m France it is EPSG:2154, called "RGF93 / Lambert-93")

If you look at Screenshot 2 you can see the imported modell of the IGN 5m Source-data. Each colored layer represents an altitude level of 1m, so the outside blue equals 1762m and less, up to 1783m on its highest level where the arrow points. You can see that the highest point of the source data is next to the position of the underlying blue "lookout" symbol, being near the survey point of the peak. So the import of source data is correct.

477b715e3804de42cf4275569fb6f29e


3)

Reprojection and Resampling.

Finally the Sourcedata hast to be reprojected and resampled to create the 1" files of DTM France 1". This means on predifined, fixed coordinates, which are about 20 x 30 m away from each other, the elevation values of the source modell are taken into the final 1" modell. Have a look at Screenshot 3: Underlying the source modell of Screenshot 2, and above the rectangular 1"-HGT files of the final DTM 1". The elevation of the source data on the CENTER of a DTM 1"-HGT cell equals exactly the elevation of the whole cell. That's the simple magic of resampling.


This is why the highest cell of the final 1" can not always be exactly at the postion of the real summit of source data, but somewhere outside. In the example the highest hgt cell is northwest of the real summit with an elevation of 1778m - which is a correct sample of the underlying "1778.189 m" of the source data. The job of resampling is NOT to reproduce exact locations and elevation of peaks - the job is to keep the exact elevation in the CENTER of the HGT-cell.


Important: the finer the DTM, the better in can reproduce the form, postion and elevations in steep, rocky terrain. That's why I advice anybode to use 1" instead of 3" DTMs if they are used outside the lowlands.

00d6403cf7971a73582a26af82f8c85a

photo
1

100% Right. And also with 1" resolution (~30m at Equartor) the Middlepoints often dont hit 5m wide Rivers (canyons) or cliffs at Mountains. So i decided or "need" to use at least 0.125" resolution for height data in Locus.

(height data "just" necessary for getting height values or Profiles) 0.125" are roundabout 3 m Resolution at my Region.


And For additional resolution in Visualisation i decided to export highres data as Raster Hillshade Map with ~0.5 m Resolution.


There i get nearby all small cliffs visible exactly. And also paths in Forested Regions get visible.

Replies have been locked on this page!