lidar2map — free tool to generate LiDAR relief maps (hillshade / SVF) for Locus

[nico579]

Hi all,

A sibling to the gpxsolar tool I posted here recently — same idea, different data.

lidar2map is a free open-source tool (GPLv3) that turns high-resolution LiDAR into shaded-relief map overlays you can load in Locus Map. It downloads the elevation data, builds the relief, and tiles it for you.

What it produces: multidirectional hillshade and Sky-View Factor (SVF) relief — the kind of visualization that reveals micro-terrain you can't see on satellite or standard maps (old paths, terraces, earthworks, drainage). Useful for hiking route-finding and terrain reading.



Same place: satellite, OpenStreetMap, then the LiDAR relief (SVF) — the relief reveals what the other two don't show.

And loaded as an overlay inside Locus Map:



Heads-up on coverage: the built-in data source is the French national LiDAR HD (IGN), so out of the box it covers France only. The processing itself is generic — if you have your own LiDAR tiles for another region, the relief pipeline works on those too.

How to use it in Locus Map:
[list=1]

• Generate an MBTiles or SQLiteDB output (the SQLiteDB uses the RMaps schema Locus reads natively).
• Load it as a map overlay (Settings → Maps → overlay), or as a standalone map.
• Stack it under your usual map at reduced opacity to combine relief with your base layer.

Outputs: MBTiles (universal), SQLiteDB (RMaps schema — Locus / OsmAnd), Mapsforge .map, RMAP (CompeGPS / TwoNav). Runs on Windows / Linux / macOS, GUI or CLI.

Repo (code, build, docs): https://github.com/nico579/lidar2map

Hobby project — feedback welcome, especially on the Locus loading side.

[nico579]

Update, one month later: no longer France-only.

Since the original post, lidar2map has grown from 1 to 30+ LiDAR sources
covering 20+ countries. For Locus users the highlights are probably:

- Czechia: CUZK DMR 5G (1 m)
- Austria: Tyrol and East Tyrol (0.5 m)
- Germany: Bavaria, NRW, Lower Saxony, Thuringia (1 m)
- Switzerland: swissALTI3D (0.5 m)
- Netherlands: AHN (0.5 m)
- UK: England, Scotland, Wales
- Plus Scandinavia, Estonia, Poland, Slovenia, Spain, Japan, US, Canada,
  Australia, New Zealand...

The pipeline is unchanged: pick a town or a bbox, the tool downloads the
official national LiDAR tiles, computes archaeology-oriented visualizations
(hillshade, SVF, openness, LRM, plus a new VAT composite that combines
them into a single readable layer), and produces offline MBTiles/SQLiteDB
ready to drop into Locus. There is now a small GUI, so no command line
needed, presets that auto-tune the visualization to each country's
resolution, and the tile cache is compressed by default (about half the
disk space).

Still free and GPL: https://github.com/nico579/lidar2map/releases

If you try it on your local data, especially in CZ/AT/DE, I would really
appreciate feedback on how the maps behave in Locus in the field.

[RafaelV FR]

Hello Nico,

First, bravo for your tools.

I generated a SQLiteDB output. Ubuntu 24.04 LTS, standalone executable.
France, Thones city, 20 km radius, no changes on others seetings.

I imported the lidar map into Locus map (Android), version 4.35 (06/2026), with "import map" process from Locus map manual  https://docs.locusmap.app/doku.php/manual:user_guide:maps_external. No warning.

But this map is not present in Map overlays list (OFFLINE/MAPS).

I checked the directory Android/data/menion.android.locus/files/Locus/maps. The file is here but greyed out. I think this means unsupported files.

I can see in the directory, not greyded out, others offline maps I use (from IGN).

[nico579]

Hi RafaelV,

First, sorry for the slow reply, your message sat unseen for a couple of weeks.

Thanks a lot for the kind words, and for the precise report (folder path, Locus version, the greyed-out detail). That is exactly what was needed to pin it down.

Here is what is going on. Both Locus and OsmAnd read the SQLite tile format, but they use a different internal tile-numbering convention. The .sqlitedb that the tool writes is set up for OsmAnd's convention (tilenumbering = "simple"), which Locus does not accept as-is, so it shows the file greyed out. The map itself is fine, it is just labelled for the other app.

 The fix is easy: use the .mbtiles file instead. The tool generates it in the same output folder, with the same name as your .sqlitedb but the .mbtiles extension (MBTiles is produced by default, so it should already be sitting right next to the .sqlitedb you found). MBTiles is the universal format, Locus loads it natively, same import process. Drop it in the same maps folder and it will show up normally.

Rule of thumb: MBTiles for Locus, SQLiteDB for OsmAnd.

If the .mbtiles is not there for some reason, just re-run and make sure the MBTiles output box is ticked (it is on by default).

Thanks again for flagging this. I am relabelling the format options in the app (MBTiles = Locus/OsmAnd, SQLiteDB = OsmAnd) so the next person does not hit the same trap.

Cheers,
Nico

[Col]

Amazing, this is exactly what I was looking for, I have an older mac though, any chance you could release an x64 version or an mac-x64 build script?

[nico579]

Hi Col,

Thanks! Yes, that's doable, and it's now in the pipeline.

PyInstaller can't cross-compile, so an Intel binary has to be built on an Intel Mac. I don't have one, but GitHub's CI still provides a free Intel macOS runner (macos-15-intel, announced as available until August 2027), so I added it to the release workflow. Next release will ship lidar2map-macos-x86_64.zip alongside the arm64 one. I'll post here when the asset is up, since that build has never run yet and may need a round or two.

One question first: which macOS version is your Mac on? The GUI runs on Qt/QtWebEngine and that puts the floor around macOS 12. Below that, no build of mine will help.

Meanwhile you can run it from source today on Intel, no build needed:

git clone https://github.com/nico579/lidar2map
cd lidar2map
python3 lidar2map.py

Python 3.9+ is enough. First launch creates its own venv in ~/.lidar2map/venv, installs the dependencies and downloads the JRE and osmosis it needs (a few minutes), then the GUI opens. Same code as the packaged app, just not frozen.

Note: the Intel build ships without numba (its LLVM backend no longer provides macOS x86_64 wheels), so the SVF computation falls back to pure NumPy and is noticeably slower than on Apple Silicon. Everything works, it just takes longer.

[Col]

Thats great, Ill have a try tomorrow. Im on 15.7.7.

I did play around with your build scripts and got it to complile a working version, although i dont think everything is perfect, and it was a bit chaotic working with AI on it. To get numba working on an intel mac versions in the venv have to be python==3.12.13
numba==0.60.0 llvmlite==0.43.0 numpy 2.0.x as numba dropped intel support after this. Also I had to 'brew install libomp'

The original build i created was failing on the TIFF compression, _internal/pyproj/.dylibs/libtiff.6.dylib is called and doesnt work, _internal/rasterio/.dylibs/libtiff.6.dylib fixed the problem.

I did however notice that the maps created viewed fine unless zoomed out beyond the tile, in which case there would be a black border and flickering graphical artifacts. (maybe this is just my build)

I hope some of that info helps you, and if you need me to build/test let me know.

[Col]

I just tried version 1.31.1 and it says this when I open it:

 "LIDAR2MAP.app" is damaged and can't be opened. You should move it to the Bin.

I can still view the contents of the app.

[nico579]

Hi Col,

Thanks; all of that information is extremely useful, especially since you have access to a real Intel Mac.

The "LIDAR2MAP.app is damaged" message is a macOS Gatekeeper/signing problem rather than an indication that the ZIP download is actually corrupted.

The current build process creates the .app with PyInstaller and then copies the large internal lidar2map_bundle.zip into Contents/Resources. PyInstaller has already
applied an ad-hoc signature by that point, so adding the ZIP afterwards modifies the application and invalidates its signature. A locally built application may still
run because it has not been marked as downloaded from the Internet, whereas the GitHub download receives the macOS quarantine attribute and is checked by Gatekeeper.

As a temporary workaround, could you try:

xattr -dr com.apple.quarantine /Applications/LIDAR2MAP.app
codesign --force --deep --sign - /Applications/LIDAR2MAP.app
open /Applications/LIDAR2MAP.app

If the application is still in Downloads rather than /Applications, replace the path accordingly. You can also drag the application into the Terminal after typing
each command to insert its exact path.

I will change the packaging order so the complete application is signed only after the internal bundle has been added. That should remove the invalid-signature
"damaged" error. A fully warning-free public download will ultimately require Apple Developer ID signing and notarization as well.

Your Intel dependency findings are also very helpful. I will test an Intel-specific dependency set based on:

Python 3.12
numba 0.60.0
llvmlite 0.43.0
NumPy 2.0.x

I will also account for the Homebrew libomp dependency in the Intel build environment. I do not want to assume yet which package requires it, so I will verify the
linked libraries during the CI build.

The libtiff.6.dylib finding is particularly useful. It suggests that PyInstaller is collecting separate TIFF libraries from pyproj and rasterio, and that the runtime
loader is resolving the incompatible pyproj copy first. Replacing it with the rasterio copy demonstrates the conflict, although I will need to fix the library
collection/linking cleanly rather than blindly overwrite one copy, as that could potentially break pyproj.

Regarding the black border and flickering, there are two related issues.

The previous tiling code filled the part of a Web Mercator tile outside the actual LiDAR extent with opaque black pixels. This becomes very visible when zooming out
because one 256×256 tile can cover an area much larger than the generated LiDAR map. Version 1.31.1 changes those border tiles to PNG with transparent padding.

However, Locus does not appear to alpha-composite overlapping tiles supplied by several MBTiles files. When multiple split maps contain the same (zoom, x, y) tile,
Locus may display only one complete tile or alternate between competing files while zooming. That can produce gaps, black borders or flickering even when the padding
itself is transparent.

Could you therefore test directly in Locus with:

- only one newly generated MBTiles enabled;
- all older versions of the same map disabled or removed;
- no split/block output for this test;
- forced tile regeneration, so an older cached MBTiles is not reused.

If a single freshly generated MBTiles still shows the black border or flickering in Locus, could you send me:

- a screenshot or short screen recording;
- the exact generation command or relevant log;
- the shading type and zoom range;
- whether the output was MBTiles, RMAP or SQLiteDB;
- and, if practical, the smallest MBTiles file that reproduces it.

That will let me determine whether there is another tiling issue or a Locus rendering problem unrelated to overlapping files.

Thanks again for testing this and for documenting the Intel build work. Your findings already point to several concrete improvements, and your offer to build or test future Intel versions would be very helpful.

[RafaelV FR]

Hello Nico,

Thanks for your answer and modifications.

I re-run process with last version of standalone executable, with LRM output. Always on Ubuntu 24.04 LTS.

It worked. I copied the file into my phone and imported it in Locus Map with process "Map manager/Import map/System file manager/".
On Locus Map, I use it with overlay feature (at 60% transparency), over the Offline LoMap. But it work also as main map.
Many thanks. It is very useful to see the real ground on the map. This will help me a lot to update Open Street Map after my hikes.

Note : The second process to import map describe in Locus Map manual, "File browser/find the map file in your local storage/long-press its name and select open or send to" does not work. I have message "Recheche sur le Play Store ? Aucune application ne peut ouvrir ce type de fichier. Vous pouvez en rechercher une dans le Play Store".
My phone is Samsung Galaxy A56 5G, Android 16, One UI version 8.5 

The Telephone button show the a window "Aucun livrable ...."  because no file in the directory. I check, and it's correct. No .mbtiles file in the directory. 
To see screen shots with the links.
https://filedn.eu/lgN2Me5QYcTztc2zQgK8OJ7/Telephone%20button%20-%20message.png
https://filedn.eu/lgN2Me5QYcTztc2zQgK8OJ7/Windows%20openned%20at%20end%20of%20process.png
https://filedn.eu/lgN2Me5QYcTztc2zQgK8OJ7/Directory%20used%20by%20Telephone%20button.png
I manually copied the .mbtiles file into the directory, but same problem.
So I could not test this function, who is very very useful.

Note. I previously run lidar2map, for same area, SQLiteDB and Multi output, and the output file was 2 Go. It was quite huge. With LRM output, is is a lot smaller 674 Mo.
I not yet understood all these different outputs, for which use, but I have to read again the doc.

[RafaelV FR]

Hello Nico,

I tried slope output and rrim output. Both worked.

Note: the Telephone button worked fine for rrim output, but not for slope output (same window than for rlm).
I could download the slope and rrim files into my phone thought wifi.
The "open file" button in the phone worked here. I could select Locus Map and import files.

[nico579]

Hello Rafael,

Thank you for the additional tests and screenshots. They revealed two separate issues.

The Android "Open or send to" failure does not mean that the MBTiles file is invalid. On your Android 16 / Samsung / Locus Map combination, the system file browser does not associate the .mbtiles extension with Locus. This is why Android proposes searching the Play Store.

The reliable method is therefore the one that worked for you:

  Locus Map > Map Manager > Import map > System file manager

  Locus then imports the same MBTiles file correctly, either as a main map or as an overlay.

The empty page displayed by lidar2map's Phone button was a separate Linux-specific bug. Automatically generated project folder names are normalized to lowercase, for example "Thones" becomes "thones", but the Phone function was still looking for the spelling entered in the interface. Ubuntu treats those as two different paths, so lidar2map could report "No deliverable" even though the MBTiles file existed.

This has now been fixed. The Phone function uses exactly the same project path as the generation pipeline, also handles custom output directories, and searches recursively for all supported map files.

Please redownload and extract the current v1.31.2 Linux archive, which was refreshed on 1 August:

https://github.com/nico579/lidar2map/releases/tag/v1.31.2

It should now list LRM, slope, RRIM and the other generated maps in the same way.

About the file sizes: SQLiteDB and MBTiles contain essentially the same already-compressed tile images; conversion to SQLiteDB does not recompress them. The main difference therefore comes from the visualization itself and its ability to be compressed. Multi hillshade contains tonal variation over almost the whole image, whereas LRM removes broad relief and often leaves large, nearly uniform areas that compress very efficiently. Consequently, 2 GB for Multi and 674 MB for LRM can be perfectly normal for the same extent and zoom levels.

For small terrain details, my personal favourite remains LRM with sigma=3. I find it useful to compare it with VAT, positive openness O+, and negative openness O−, because these visualizations emphasize complementary aspects of the terrain.

I have also added a guide explaining the history, formulas, advantages and limitations of the different visualizations, with diagrams:

English:
  https://github.com/nico579/lidar2map/blob/main/docs/shadings.md

French:
  https://github.com/nico579/lidar2map/blob/main/docs/shadings.fr.md

Thank you again for the careful testing. Your screenshots made the Linux path bug much easier to identify.

Cheers,
Nico

[RafaelV FR]

Hello Nico,

No problem with the new release. I tested Slope, LRM, RRIM and SVF output type. Everything works well.

I read the guide (in French). It is technical as it must be and even if I did not understood everything, I understood small things which help me.

I'm testing different outputs type and parameters, but at this step, SVF seems good to see path and tracks for hiking. I will continue.

Thanks again for this tool and the fast answers.

Regards
Rafael

[nico579]

Hello Rafael,

I originally designed Lidar2Map for my own use, because I love discovering old paths hidden beneath vegetation.

I often explore forests with a saw and pruning shears, looking for traces of past human activity far from cities: forgotten paths, dry-stone terraces, ruins, charcoal-burning sites, lime kilns, and more.

I usually prepare my explorations with QGIS, which can read most of the files generated by Lidar2Map, including MBTiles and GeoJSON. Then, in the field, I use Locus Map to explore and navigate, comparing my position with the remains revealed by the LiDAR data.

I'm glad that SVF seems useful for finding paths and hiking tracks. I hope Lidar2Map will help you discover many interesting places!

Regards,
Nico

[Col]

Hi Col,

Thanks; all of that information is extremely useful, especially since you have access to a real Intel Mac.

I tried with release 1.31.5 and once

xattr-dr com.apple.quarantine /Applications/LIDAR2MAP.app

Has been applied the app runs and creates output absolutely fine, if a little slow, not sure if you have added numba etc to the build.

There is no tile border when the maps are used as an overlay, but when they are used as the main map and you zoom out beyond the tile border, there is now a large grey box, not sure if this is the map or a problem in locus. I tried this with VAT,LRM,SVF,O+ & O-.I dont have any other mbtiles maps to check this with, but it doesn't appear to happen with the other sqlitedb maps.