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

[nico579]

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.

[Col]

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

[nico579]

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.

[Col]

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.

[nico579]

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.