Locus Map - forum

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.

(https://raw.githubusercontent.com/nico579/lidar2map/main/screenshots/LIDAR_Samples/relief_3views.jpg)

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:

(https://raw.githubusercontent.com/nico579/lidar2map/main/screenshots/LIDAR_Samples/Svf_LocusMap.jpg)

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.

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.

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

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

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?

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.

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.

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.

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.

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.

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.

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

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

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

Quote from: nico579 on July 31, 2026, 13:58:25Hi 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.

Hi Col,

Thanks for confirming, glad the Gatekeeper workaround got you running, and that the tile border is gone now that the map is used as an overlay.

While testing multi-block splits myself, I found and fixed a related class of bug that might be relevant to what you're seeing when zoomed out on a split map. Each block's output extent was computed independently, and a straight edge does not stay perfectly straight once you reproject from the source CRS to Web Mercator. Two separate issues came from that: neighboring blocks disagreed slightly on where their shared edge actually was, and at points where four blocks meet, each of the four computed a slightly different position for that shared corner, leaving a small area with no published tiles right at the junction.

Both are now fixed. Adjacent blocks compute their shared boundary from the exact same reference points, so they agree exactly. For the four-way corner, each block now merges in the real, already-computed data from its neighbors before warping, so the small gap gets filled with real pixels rather than being left empty. This will be in the next release.

That said, I'm not yet sure this is the same bug behind your grey box. Your symptom is specifically when a map is used as the main map and you zoom out past the tile border, not at an internal seam between two blocks, so it could be a distinct issue, possibly how Locus handles areas outside a layer's coverage when it's the base map rather than an overlay. Could you help me narrow it down:

- Was the file you tested a single (non-split) MBTiles, or did it come from a multi-block split?
- MBTiles or RMAP? (you mentioned it doesn't happen with your sqlitedb maps, so I assume MBTiles)
- A screenshot of the grey box would help a lot.
- Does it appear right at the edge of the map's actual coverage, or only once you're zoomed out past its max data zoom?

Thanks again, your testing has been extremely valuable, especially with the Intel Mac access.

Hi.
It is a non split mbtiles map, and the grey box is there no matter the zoom, but it gets proportionally bigger compared to the map tile coverage as you zoom out. It also disappears when you get to zoom level 8, and it disappears on 2 sides at zoom 18 (top and bottom) with one side grey and the other a black area.

https://photos.app.goo.gl/eUwJKJkAvjD6S2e66

https://photos.app.goo.gl/6bFmoyczov1nn7Dv9

Hi Col,

Thanks, this description is very helpful. I was not able to open the photo links on my end, so what follows is based on your written description rather
than the screenshots themselves, let me know if I got any detail wrong.

I think these are actually two different things.

The black one is a real bug I found and fixed.
When lidar2map reprojects the source raster from its native CRS (Lambert93 for France) to Web Mercator
for tiling, a rectangle in the native CRS does not stay perfectly rectangular after reprojection,
it comes out very slightly rotated.

The warped file is still written as an axis-aligned rectangle (the bounding box of that rotated shape),
so its own corners contain a thin wedge that falls outside the true data footprint.
The reprojection step was not marking that wedge as nodata, so it got filled with black and treated as if it were real data.

On the test zone I used to reproduce this, about 2% of the pixels near the corners were affected.
This is now fixed: the warp step also produces a proper coverage mask, and the tiler uses it to make those wedge pixels transparent instead of opaque black.
It will be in the next release, and it applies to non-split maps too, so it should be exactly your case.

The grey one I believe is not a lidar2map bug, but how Locus itself handles a layer with limited coverage when it is used as the main map rather than an overlay.
Outside the area lidar2map actually covers, there is no tile to request at all, and Locus has to render something for that space, likely its own neutral background.
That would also explain why it disappears at very low zoom (probably below the map's declared minzoom, where Locus stops requesting the layer altogether)
and why it behaves differently from the black artifact, which is a real opaque pixel inside a real tile, not a gap.

If you get a chance to test the next build once it is out, I would be curious whether the black area is gone and whether the grey one is still there
and behaves the same regardless of shading type. That would confirm the two are unrelated.

Thanks again for the detailed writeup, and sorry I could not view the screenshots directly, if I misread anything from the description just let me know.

Thanks for your detailed explanation. Sorry about the photos, i accidently deleted them but the links should work again now. I'll test once the release is out.

Thanks, the links worked this time.

Both screenshots match what I expected:

The black band one is exactly the nodata wedge bug, confirmed. It's already fixed and live in the current build, you don't need to wait for a separate release announcement, a fresh download/update should have it now.

The grey checkerboard right next to the black band is not a lidar2map issue, it's Locus's own placeholder for "no tile available here." That one is expected behavior, not something to fix.

The zoomed out overview (whole trek, 20 km scale) also makes sense: I can see a couple of rectangles with sharp edges (one around the 462 m point, another one further up with several of your day checkpoints). Those are just the boundaries of the zones you generated with lidar2map, the base map fills in outside them. Same idea as the grey checkerboard, just at a bigger scale.

So after you update: the black band should be gone, but you'll still see the sharp rectangle edges and occasional grey checkerboard at the boundary of your covered zones, that part is normal and not going to change.

One tip that should help with the grey checkerboard specifically: set the lidar2map shading as your main map and OSM as an overlay on top, rather than the other way round. OSM is vector, so it always renders everywhere with no gaps, whereas the shading only exists inside the rectangle you generated. With OSM layered on top, it fills in the checkerboard outside that rectangle instead of leaving it blank, while the relief shading stays the dominant thing you see inside the covered area.

For that OSM overlay, you can generate it with lidar2map itself, no need for a separate tool:
--osm --layer "highway=path highway=track highway=footway" --file-formats map
gives you just the paths/tracks as a Mapsforge .map file, which is what Locus wants for an overlay.

On the speed question: numba is included in all the builds (Windows/Mac/Linux), so it should already be active on your end.
You'd see a line like "SVF Numba JIT: compiling on first call" near the start of a run if it's kicking in.
If it's still slow for large areas, that's mostly a hardware/scale thing rather than something the build is missing, SVF and openness over a big zone are genuinely CPU heavy.
If you want it faster on big areas, running it on a cloud VM (a few euros/hour on something like Hetzner) via lidar2map's `--remote-cli` mode is an option, it just gives you more cores than a laptop for the duration of the run.

Hi Nico,
all has been working great apart from one thing a found.Im using bounding boxes and have an area of the Lake district selected for which the corner juts out into the sea near where there is a nuclear submarine manufacturing facility. There is an area of sea which im assuming belongs to that, but rather than a 'no coverage' being returned, i get lots of Http 500 errors then the process fails. if i reduce the box a little to exclude the area -3.421000, 54.138400, -3.376200, 54.210300 then all is good :

$ /Users/mus/Library/Application Support/lidar2map/lidar2map --provider gb-england --zone-bbox -3.512468,54.144741,-2.624122,54.959754 --zone-width 20 --zone-name Lakes --output-dir /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/Lakes/ --cache-dir /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/-cache/ --production-dir /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/-production/ --lidar --download --workers 8 --shading vat:dist=20,gamma=2 --shading opos:dist=20,gamma=2,sweep=1 --svf-sweep --file-formats mbtiles --zoom-min 8 --zoom-max 17 --image-format jpeg --image-quality 85

  Log : /Users/mus/Applications/logs/lidar_20260821_101849_20630.log (publication atomique à la fin)
  History: entry '1787303928287-11242-gui' (in progress)
=======================================================
  LiDAR : Royaume-Uni (Angleterre) — LIDAR Composite DTM (EA)
  Pipeline rasterio + numpy (numba for SVF)
=======================================================
  Folder : /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/Lakes/
  BBox WGS84 : -3.5125,54.1447 → -2.6241,54.9598
  BBox EPSG:27700 : 301301,472281 → 360133,563838
  Area: ~5386 km²
STEP:1/3 Downloading tiles
  -> Compression enabled
  Root    : /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/Lakes
  Tiles  : /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/-cache/lidar/gb
  Zone    : /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/Lakes
  LiDAR tiles [░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  0%  24/5391  19s
  ERROR dtm_england_301_489.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  2%  115/5391  1m37s
  ERROR dtm_england_302_489.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  3%  206/5391  2m37s
  ERROR dtm_england_303_489.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  283/5391  3m34s
  ERROR dtm_england_304_479.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  284/5391  3m39s
  ERROR dtm_england_304_481.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  285/5391  3m39s
  ERROR dtm_england_304_483.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  286/5391  3m40s
  ERROR dtm_england_304_482.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  287/5391  3m40s
  ERROR dtm_england_304_480.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  289/5391  3m41s
  ERROR dtm_england_304_484.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  290/5391  3m43s
  ERROR dtm_england_304_485.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  291/5391  3m44s
  ERROR dtm_england_304_486.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  295/5391  3m49s
  ERROR dtm_england_304_487.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  5%  296/5391  3m50s
  ERROR dtm_england_304_488.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [██░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  7%  379/5391  4m57s
  ERROR dtm_england_305_479.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [██░░░░░░░░░░░░░░░░░░░░░░░░░░░░]  8%  480/5391  6m11s
  ERROR dtm_england_306_479.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [███░░░░░░░░░░░░░░░░░░░░░░░░░░░]  10%  569/5391  7m19s
  ERROR dtm_england_307_479.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [███░░░░░░░░░░░░░░░░░░░░░░░░░░░]  12%  656/5391  8m28s
  ERROR dtm_england_308_479.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  736/5391  9m23s
  ERROR dtm_england_309_472.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  737/5391  9m27s
  ERROR dtm_england_309_473.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  738/5391  9m27s
  ERROR dtm_england_309_474.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  740/5391  9m29s
  ERROR dtm_england_309_475.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  745/5391  9m32s
  ERROR dtm_england_309_476.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  748/5391  9m33s
  ERROR dtm_england_309_477.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [████░░░░░░░░░░░░░░░░░░░░░░░░░░]  13%  750/5391  9m34s
  ERROR dtm_england_309_478.tif (OSError, attempt 3): HTTP 500
  LiDAR tiles [███████░░░░░░░░░░░░░░░░░░░░░░░]  23%  1279/5391  17m24s
  ERROR dtm_england_314_511.tif (TimeoutError, attempt 3): The read operation timed out
  LiDAR tiles [███████░░░░░░░░░░░░░░░░░░░░░░░]  26%  1410/5391  21m39s
  ERROR dtm_england_316_483.tif (TimeoutError, attempt 3): The read operation timed out
  LiDAR tiles [██████████████████░░░░░░░░░░░░]  61%  3320/5391  46m45s
  ERROR dtm_england_337_482.tif (TimeoutError, attempt 3): The read operation timed out
  LiDAR tiles [██████████████████░░░░░░░░░░░░]  62%  3356/5391  48m56s
  ERROR dtm_england_337_524.tif (TimeoutError, attempt 3): The read operation timed out
  LiDAR tiles [██████████████████░░░░░░░░░░░░]  62%  3358/5391  49m31s
  ERROR dtm_england_337_529.tif (TimeoutError, attempt 3): The read operation timed out
  LiDAR tiles [██████████████████████████████] 100%  5391/5391  1h12m47s
  Downloaded: 5362  Cache: 129  Missing: 0  Errors: 29
  History saved: /Users/mus/Applications/historique.json  (9 entries)
[PYI-20630:ERROR] Failed to execute script '_loader' due to unhandled exception: 29 tile download error(s) - pipeline stopped before shading/tiling (rerun to retry the failed tiles; successful ones are cached)
[PYI-20630:ERROR] Traceback:
Traceback (most recent call last):
  File "_loader.py", line 36, in <module>
  File "<frozen runpy>", line 287, in run_path
  File "<frozen runpy>", line 98, in _run_module_code
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 11116, in <module>
    _dispatch()
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 11031, in _dispatch
    return main()    # --lidar / --osm / par défaut
          ^^^^^^
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 5564, in main
    _telecharger_dalles_zone(dalles_dict, bbox, dossier_dalles, dossier_ville, args)
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 6156, in _telecharger_dalles_zone
    return _telecharger_dalles_zone_impl(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "_terrain_download.py", line 255, in telecharger_dalles_zone
RuntimeError: 29 tile download error(s) - pipeline stopped before shading/tiling (rerun to retry the failed tiles; successful ones are cached)
UNHANDLED EXCEPTION:
Traceback (most recent call last):
  File "_loader.py", line 36, in <module>
  File "<frozen runpy>", line 287, in run_path
  File "<frozen runpy>", line 98, in _run_module_code
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 11116, in <module>
    _dispatch()
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 11031, in _dispatch
    return main()    # --lidar / --osm / par défaut
          ^^^^^^
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 5564, in main
    _telecharger_dalles_zone(dalles_dict, bbox, dossier_dalles, dossier_ville, args)
  File "/Users/mus/Library/Application Support/lidar2map/_internal/lidar2map.py", line 6156, in _telecharger_dalles_zone
    return _telecharger_dalles_zone_impl(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "_terrain_download.py", line 255, in telecharger_dalles_zone
RuntimeError: 29 tile download error(s) - pipeline stopped before shading/tiling (rerun to retry the failed tiles; successful ones are cached)

✗ Terminé (code 1)
  History saved: /Users/mus/Applications/historique.json


Hi Col,

Thanks for the detailed report, that pinpointed it fast.
Confirmed and fixed: your bbox corner falls outside the real EA LIDAR coverage (sea near the Barrow-in-Furness naval yard), and their WCS server returns HTTP 500 for those out-of-coverage tiles instead of a clean 404. lidar2map was treating 500 as a hard error, so after 3 retries per tile it aborted the whole run, even though 5362/5391 tiles (99.5%) had already downloaded fine.

Fix: gb-england now treats that specific WCS 500 the same as a missing tile (skip, don't fail).
It's in v1.47.1, just tagged, build is running now (~30 min for all 3 platforms), should be up within the hour.

Your workaround (trimming the bbox) still works fine in the meantime, but you shouldn't need it once you update.

thanks for your quick fixes. I did mean to ask what if anything you are using to merge .mbtiles files?

Update:
I extended --merge to handle .mbtiles sources directly now, not just GeoJSON.
Same flag, same GUI tab (now just called "Merge"), it detects the file type from the sources you give it:

python lidar2map.py --merge --source zone_nord.mbtiles zone_sud.mbtiles --output-file merged.mbtiles

Bounds and zoom range become the union of the sources;
if two sources overlap on the same tile, the last one listed wins.
Add --file-formats rmap sqlitedb if you also want those outputs.
This will land in the next release.

Again great stuff. one more error i occasionally notice is:

✓ Step 3 finished in 44m25s  (cumulative 2h13m40s)
  (index sheet: reverse geocoding failed: URLError: <urlopen error [Errno 8] nodename nor servname provided, or not known>)
  lakes_opos_20m_g2p0_ombrage_z8-17_planche.png : index sheet (1000x968)
  lakes_vat_20m_g2p0_ombrage_z8-17_planche.png : index sheet (1000x968)
  Done! Folder: /Volumes/Reservoir-A/_Colonel/Maps/_Lidar2map/North Pennines
  Total time: 133m40s
  History saved: /Users/mus/Applications/historique.json  (20 entries)

✓ Terminé (code 0)
  History saved: /Users/mus/Applications/historique.json

That error is a DNS lookup failure (errno 8 = getaddrinfo couldn't resolve the hostname),
not something that breaks your run: it's from a best-effort reverse-geocoding call (looking up which department your zone is in, purely to draw its outline on the index sheet).
It was already non-fatal by design, which is why your run finished fine with code 0 and both index sheets got produced.

The "occasionally" was a transient network blip at that exact moment on a long run.
I added a retry (one retry, 2s wait) around that specific call in v1.48.2, currently building.
Should cut down how often you see it.

i seem to be getting the same problem of it failing after numerous HTTP 403 errors

ERROR dtm_england_294_548.tif (OSError, attempt 3): HTTP 403

version 1.48.2

Thanks for the report.
Found the cause: it's not a real access denial, the EA WCS server (gb-england LIDAR Composite DTM) throttles under sustained parallel requests and returns HTTP 403 instead of a proper rate-limit response.
The retry logic was only waiting ~5s between attempts, way too short for the throttle window to clear, so tiles kept failing and the whole run aborted.

Fixed: retries on 403/429/503 now back off much longer (30s, then 60s) before giving up on a tile.
Pushed to source, will ship in the next tagged release (after v1.48.2).
I'll post here once it's out, in the meantime a re-run with fewer parallel workers should also help if you hit it again before the update lands.

Hello Nico,

I have a problem with lidar2map release 1.49 1.50 and 1.50.1

On Locus map last version (4.36.0), with lidar2map type svf as overlay. Same problem with slope and rrim.
Screenshot_20260921_180324_Locus Map.jpg

Linux Ubuntu 24.04LTS
Lidar2map : Application binaire autonome
Settings
Capture d'écran du 2026-09-21 18-20-09.png

Other information.

Terminal output at start:
Capture d'écran du 2026-09-21 19-35-58.png

lidar2map runs into my webrowser Firefox (not into a terminal windows as previously).

I do not know if it is important, but to be as accurate as possible.