Messages

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

[lidar2map]

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.

[gpxsolar]

Hi all,

freischneider kindly pointed me here from the ideas site — this is the right board for it.

I made gpxsolar, a free open-source tool (GPLv3) that computes where sun and shadow fall along a GPX track at a given date and time, using elevation data and the terrain horizon. It exports a map overlay you can load directly in Locus Map.

Why it's useful on the trail: on a summer hike you want to know which sections will be in shade at 2 p.m.; in winter, where the sun still reaches; for photography, where the light hits. The overlay shows it at a glance.



Same track, three times of day — the cast shadow moves across the terrain.

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

• Load the generated MBTiles as a map overlay (Settings → Maps → overlay).
• Import the colored track KML as a regular track (the overlay is a raster, so the track comes separately).
• Keep the overlay opacity at 100%. The semi-transparency is already baked into the tiles — if you lower Locus's layer opacity, Locus re-composites the tiles and faint seams appear between them. At 100% it's seamless.

Outputs: KMZ (Google Earth), MBTiles (Locus / OsmAnd overlay), colored track KML. Input is a GPX + a date/time. Runs on Windows / Linux / macOS, GUI or CLI.

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

It's a hobby project — feedback very welcome, especially from people who load custom overlays in Locus.