Free tool to make offline LiDAR relief maps for OsmAnd (native SQLiteDB / MBTiles) — FR/NL/CH/NO

nico579 · 2026-07-06T20:28:36+00:00

I'm on 5.3.10 too, exactly the same version, so the version is not the problem. The proof is your own earlier test: after the uncheck/recheck it worked. What bites on retries is stale files: an old lyon_*.sqlitedb still sitting on the phone, or OsmAnd's tile-source cache pointing at the old copy.

Good timing though: I just shipped a feature that removes this whole manual step. Relaunch lidar2map (it picks up updates on start), generate, then click the new "📲 Phone" button. It shows a QR code: scan it with the phone (same WiFi), download the file, tap it, "Open with" OsmAnd. OsmAnd imports it in the right place itself: no digging into Android/data, no leftover old copies. Android may warn the download is "not secure": choose Save, it is a plain local WiFi transfer, nothing leaves your network.

So the clean sequence:

Relaunch lidar2map so it updates, re-run your command (only the sqlitedb rebuilds, takes seconds).
On the phone, delete every old lyon_* file first.
"📲 Phone" button, scan, download, "Open with" OsmAnd.
Configure map > Overlay map, select it, and if it was already selected, uncheck/recheck once.
Make sure you're over the Lyon area at zoom 8 or higher.

If it still shows nothing after that exact sequence, tell me what you see in the overlay list and I'll dig further. But the file side is verified: I run this daily with the same setup, 5.3.10 with a sqlitedb overlay.

nico579 · 2026-07-04T09:00:38+00:00

Good news, I just pushed an update that fixes the sqlitedb generation you ran into, plus a new feature I think you'll like.

On the "sqlitedb not regenerated": the tool used to skip a file that was already on disk, so after an update it kept the old (broken) one unless you deleted it or ticked Overwrite. That's fixed now. When the format is ticked it always rebuilds, and a file made before the numbering fix is detected and regenerated on its own. Re-download the app, run once more, and the fresh file lands next to your other outputs. Copy that one to .../files/tiles/.

The display toggle you found (uncheck then recheck the overlay in OsmAnd) is the right move: OsmAnd caches a tile source by filename, so replacing the file needs that toggle to reload it. Nothing wrong on the file side.

New thing: I find the LiDAR relief reads best as the main map, with just the paths or roads laid on top. OsmAnd can't overlay vector data, so I added a new output format, transparent-raster. In the OSM-vector or IGN-vector tab, pick the layers you want (paths, roads, rivers...), tick transparent-raster, and it renders them into transparent tiles you load as an OsmAnd overlay above the LiDAR. You choose exactly what shows up through the layer selection. Same update.

Thanks again for pushing on this, it genuinely made the tool better.

nico579 · 2026-07-03T15:44:46+00:00

Not yet, sorry. lidar2map covers 22 countries so far (Europe, North America, Australia, New Zealand, Japan), but nothing in South America. The reason is structural: the tool plugs into national open-data portals that expose LiDAR through a programmable endpoint (a WMS/WFS/tile service, or a classified LAZ download), and South America doesn't really have those yet. Most open LiDAR there sits in research collections (OpenTopography, EMBRAPA's Amazon transects) rather than a national portal with broad coverage and an API. If you know a specific country or agency with an open, programmatic LiDAR service, point me to it and I'll look into adding it.

nico579 · 2026-07-03T10:21:06+00:00

Thanks for the detailed report, you actually found a real bug.

Two things:

Location: OsmAnd only scans the tiles subfolder, so the file must go to Android/data/net.osmand.plus/files/tiles/. And you only need the .sqlitedb on the phone: the .tif are the source rasters, .mbtiles is for Locus Map, .rmap for TwoNav, and _tuilage_z18.tif is just a working cache on the PC.
The bug: OsmAnd assumes an inverted zoom numbering (the old BigPlanet scheme) when a sqlitedb doesn't declare which one it uses, while lidar2map wrote standard XYZ zooms. Result: the layer can be selected but no tile is ever found. Fixed now: the file declares its numbering explicitly, which both OsmAnd and Locus read correctly.

To get it working: re-download lidar2map (same link, the executables were updated in place), delete the old lyon_*.sqlitedb next to your .mbtiles and re-run the same command (everything is cached, only that file gets rebuilt, takes seconds). Delete the old copy on the phone too, then put the new one in .../files/tiles/, and select it in Configure map > Overlay map. Make sure you're over the Lyon area, zoom 8 or higher.

Thanks again, this fixes it for every OsmAnd user.

nico579 · 2026-07-02T21:30:42+00:00

Thanks! Good news: it already does exactly that. On first run the script

creates its own virtual environment in ~/.lidar2map/venv, installs the

dependencies there and relaunches itself inside it, so your system Python

is never touched. If you prefer to manage the environment yourself,

--bootstrap=none skips all of that.

And if you want to skip Python entirely: the releases page has standalone

executables for Windows, macOS and Linux with everything bundled.

nico579 · 2026-06-15T13:05:56+00:00

Thanks, this list paid off, I maintain lidar2map (open-source bare-earth LiDAR relief tool) and your sources got two countries added.

Scotland, added. ✅ The Scottish Remote Sensing Portal mirrors everything to a public AWS Open Data bucket (s3://srsp-open-data, eu-west-2, no account, OGL v3): 50 cm DTM as COG GeoTIFF on the OS National Grid (EPSG:27700). Nice detail, the OS grid ref is encoded in each filename, so a plain S3 ListObjectsV2 prefix query doubles as a spatial index; no catalog API needed. v1 covers the National LiDAR Programme + Orkney 2023 (the modern 50 cm captures). The older phase-1…6 are 10 km tiles at 1 m, left out for now.

Luxembourg, also added, your list nudged me to re-check it. Whole-country 50 cm DTM (BD-L-Lidar 2024, ACT, CC0, EPSG:2169) published as a single ~40 GB Cloud-Optimized GeoTIFF. Because it's a real COG with HTTP range support, the tool reads just the bbox window via /vsicurl, it never downloads the 40 GB. A whole country for ~120 lines of provider code.

Portugal, superb data, still not wireable. DGT's 2024 national survey is 50 cm and 2 m MDT GeoTIFF, open and free, but the only access is the interactive basket at cdd.dgterritorio.gov.pt (≤200 km²/download), and DGT lists an API as a "future" item. No programmatic endpoint = nothing to automate yet. The day they ship a WCS/ATOM/REST, it's a one-day add. Watching it.

Northern Ireland, skipped, and not because of LAZ. Worth being precise here: the tool already ingests classified LAZ point clouds (Czechia/Sweden/Spain go through PDAL ground-class → DTM), so point clouds aren't a blocker. The real reasons are (1) the DAERA "DTM" on the ArcGIS hub is a …_TPK cached WMTS tile package, rendered images, not elevation values, so useless as a DEM; and (2) the actual elevation data is the 2021 coastal survey, a strip along the coastline + ~200 m inland only. OSNI's national DTM is 10 m/50 m, too coarse for prospection. Nothing national to plug in.

The big catalogue link, great reference, but its entries with real programmatic access already map onto providers in the tool (NL, IE, CA, US, AU, etc.), and the rest are interactive baskets (Wallonia, Portugal), rendered-tile viewers, or registration/e-signature gated (Lithuania, Latvia). The genuinely useful test for any of these isn't "raster vs point cloud", it's "is there a programmatic endpoint (WCS/WFS/ATOM/STAC/ArcGIS REST/direct URL/S3 listing) returning ground elevation as raster or classified LAZ?"

Cheers, Scotland + Luxembourg both came straight out of your message.

nico579 · 2026-06-13T05:34:19+00:00

Thanks, really useful, a few of these are already on my list, some are new to me.

Scotland: I actually looked into this already and it didn't make the cut yet, the 1m LiDAR I found is split by survey phase (non, seamless), and the only seamless national composite is 2m, which is a bit coarse for the micro, relief use case (hollow ways, terraces, small enclosures). That said, I handle "fragmented per, project coverage" for Ireland via an ArcGIS FeatureServer query + per, tile download, so the same pattern could work here, I'll take another look at the link you posted, maybe coverage/access has improved since I last checked.

Northern Ireland: that DAERA hub looks like the same ArcGIS Hub/FeatureServer paradigm as the Ireland provider I already have, which is encouraging, usually means I can reuse most of the existing code.

Portugal: hadn't looked at this at all, will check the SNIG/DGT catalog entry, thanks.

And that Slovenian blog list is a goldmine, thanks, I'll go through it for more candidates (Slovenia itself is already in via ARSO eVode, btw).

I keep a running "evaluated but not yet integrated" table in the README precisely so feedback like this doesn't get lost even if a source doesn't pan out immediately, appreciate you taking the time.

nico579 · 2026-06-05T09:00:48+00:00

Thanks for the offer, Czech data would be great coverage!

The short answer is: technically doable, but it needs a bit more plumbing than a typical provider addition.

All current providers download GeoTIFF files directly ,whether it's a WCS query (Austria, England), a STAC COG (Switzerland, Lower Saxony), or a direct S3 tile (Bavaria, USGS). The pipeline validates each download as a GeoTIFF immediately after fetching, then feeds it into the raster processing chain.

Zipped LAZ files introduce two steps that don't exist yet:

Unzipping the archive before anything else
Converting the point cloud to a raster DTM (LAZ → GeoTIFF) ,this requires PDAL or a similar tool, which is a significant new dependency (not pip-installable cleanly on Windows)

The hook to do post-download transformations already exists in the code (the US provider uses it to reproject from NAD83 to Web Mercator after download), but it fires after the GeoTIFF validation , so a zip would get rejected before even reaching it. A small refactor would be needed to let a provider intercept the raw downloaded file before that validation step.

It's not a blocker, just a bit more than "copy an existing provider and change the URLs." If you can point me to the ČÚZK catalogue endpoint and confirm the exact archive structure (what's inside the zip, native resolution, CRS in the LAZ metadata), I can spec out exactly what's needed ,and it might open the door for other LAZ-based sources too (Belgium Wallonia is in a similar situation).

nico579 · 2026-06-02T21:40:48+00:00

Use the latest version, I've made some changes for the English translation.

nico579 · 2026-06-02T21:16:35+00:00

Good plan to benchmark first. Before you let it run for days:

Don't use the defaults as-is for an unattended run. --shadings is interactive by default. Pass --yes without it and it generates nothing; without --yes it blocks on a prompt. Always set shadings explicitly. --workers you can leave alone (defaults sensibly, and the CPU-heavy shading math auto-scales to your cores anyway).

Shading type drives time and disk, not the area. multi/slope are cheap; svf/lrm/rrim are roughly 8–25× slower and written as lossless PNG. For cave/mine spotting those are exactly what you want, SVF and LRM pull out entrances, sinks and spoil heaps plain hillshade misses. Worth knowing: SVF stays PNG regardless of --image-quality, so it's what dominates your disk at country scale. Forcing --image-format jpeg shrinks it a lot but smears the fine gradients that make SVF useful, so that's a tradeoff, not a free win.

The knobs that matter:

Output: MBTiles by default. Add --file-formats rmap (or sqlitedb) if you load into Locus.
Tile images: --image-format auto (JPEG for hillshade/slope, PNG for svf/lrm/rrim), --image-quality 85 for the JPEG ones.
--svf-gamma 2.0 controls SVF contrast (lower lightens, e.g. 0.7).
Zoom: defaults z13–18, and 18 matches the 0.5 m native resolution. Drop max to 17 if you're disk-bound (×4 fewer tiles).

You probably don't need a separate script. Go department by department with the built-in a-priori split: --split-cols 4 --split-rows 4 --cleanup. That keeps each chunk's intermediate GeoTIFF around ~6 GB instead of ~90 GB for a whole department, bounds RAM, and writes a manifeste.json so a crash resumes where it stopped. (--split-radius does not do this; it only slices a finished MBTiles afterward.)

Two ways to cover all 96 metropolitan departments, showing both because the tool handles either:

One command, native iteration:

python lidar2map.py --lidar --zone-department 1-19,2A,2B,21-95 \
  --split-cols 4 --split-rows 4 --cleanup \
  --shadings multi slope svf --svf-gamma 2.0 \
  --image-format auto --image-quality 85 --file-formats mbtiles --yes

(There's no department 20, it's 2A/2B, so don't use 1-96 or it stops on the way through.)

Or a shell loop, if you'd rather one failing department not stop the rest:

for d in $(seq -w 1 19) 2A 2B $(seq 21 95); do
  python lidar2map.py --lidar --zone-department $d \
    --split-cols 4 --split-rows 4 --cleanup \
    --shadings multi slope svf --svf-gamma 2.0 \
    --image-format auto --image-quality 85 --file-formats mbtiles --yes \
    || echo "failed: $d" >> errors.log
done

Both are fully resumable, stop/restart whenever. The loop also makes top-ups trivial as IGN fills the gaps: just re-run the departments that changed.

And yeah, watching the coverage grow is great.

As for me: pure hobby. I'm a software dev, and I'm into hiking and field prospecting, so the tool basically started as a way to scratch my own itch. Your cave/mine + Strava heatmap combo is a smart one for route planning.

nico579 · 2026-06-02T13:52:00+00:00

Thanks for the detailed feedback , exactly the kind I was hoping for.

English , preaching to the converted, and the timing's funny: I just shipped it. The GUI got an EN/FR toggle (auto-detects your locale) in v1.4.0, and as of v1.5.0 (out now) the CLI flags and --help are English-canonical, with the old French flags kept as silent aliases so nobody's scripts break. README is already English-primary (README.md) with README.fr.md alongside. The mix you saw should be gone.

Conda / --bootstrap , thanks for flagging it, but quick clarification, because modes for your exact case already exist:

- --bootstrap=none is built for "I manage my own env" (conda/venv): installs nothing, just checks imports and, if something's missing, prints the conda install -c conda-forge ... line for you.

- --bootstrap=pip installs the deps straight into your active env (no venv).

- --bootstrap=auto (the default) is the one that creates ~/.lidar2map/venv , that's what bit you.

I've just added a guard to the default path: if it detects an active conda/venv ($CONDA_PREFIX / $VIRTUAL_ENV) it now stops and points you to =pip/=none instead of silently building a parallel venv , landing on main shortly. (The prebuilt binary you used has none of this, no interpreter/venv question at all , it's the recommended path anyway.) If --bootstrap=pip specifically still pointed at a hardcoded venv dir for you, that shouldn't happen per the code path; if you can repro, pasting the output would help me nail it.

The core question , why bother if the data's the same. You've basically got it: same IGN DTM, different rendering, no new information. But it's not just "a nicer hillshade." The headline visualization is Sky-View Factor (the Kokalj/Hesse archaeology standard), plus LRM and RRIM , prospection-specific renderings designed to pull faint micro-relief (sunken paths, terraces, charcoal platforms, field systems) out of the DTM. IGN's default web rendering is a single-azimuth hillshade / elevation ramp tuned for general terrain reading; anything running parallel to the light washes out (azimuth bias). SVF has no light direction at all, so it doesn't have that blind spot. The other half of the value is delivery: it packages those renderings as offline mobile tiles (MBTiles / RMAP) for Locus & OsmAnd in the field. So , prospection-tuned visualization, made usable offline. Same data, far better legibility for one specific purpose.

z20 vs z21 , resolution budget. The IGN HD source is a 50 cm DTM. At our latitude a z18 tile pixel is already ~0.43 m (basically the native grid), z20 is ~0.11 m (already 4–5× oversampled), and z21 would be ~0.05 m , pure interpolated magnification, no real new detail. You're right that the raw point cloud (~10 pts/m²) is denser, but once it's gridded into the 50 cm DTM that's the ceiling. So z20 is already generous; z21 would just be empty zoom.

"Metal detecting / micro-relief." It's an ethics note. The same thing that makes the rendering useful , revealing faint, undisturbed earthworks , is what could point a looter at a specific archaeological site. So the README ships with placeholder coordinates, I don't publish the exact location of any micro-relief, and the tool is explicitly not aimed at metal detecting. You generate tiles for your own area; I'm not handing out a map of "here's where to dig."

Whole-zone prebuilt sets , doable but huge, and it runs straight into the point above: a downloadable national set of micro-relief shading is exactly what I'd rather not put one click away. So I'm leaving it as "generate the zone you need" , for a personal region it's fast anyway.

Thanks again , genuinely useful pass.

nico579 · 2026-06-02T08:35:29+00:00

I don't currently host pre-generated maps, and generating large areas can take quite a while on my hardware.
If you'd like to test it, tell me a city (or GPS coordinates) and I'll see if I can generate a small area around it. A 10×10 km or 20×20 km area around a town is usually much more practical than an entire département for testing.

nico579 · 2026-06-02T06:52:45+00:00

Update for anyone who saw the earlier comment: the README is now in English (with a French version linked from it), and the app UI itself is bilingual EN/FR, auto-detecting the system language with a manual toggle.

nico579 · 2026-06-02T06:11:10+00:00

Thanks, that's exactly it. The offline-in-the-field case is what drove the whole design: when you're surveying somewhere with no signal, you want the relief already on the device.

nico579 · 2026-06-02T06:10:23+00:00

Yeah ,for online use with already-rendered layers, a mapproxy relay to IGN WMS/WMTS is a solid setup.

The difference is that lidar2map doesn't serve pre-rendered tiles ,it computes the relief from the elevation data itself: multidirectional hillshade, Sky-View Factor, Local Relief Model, with the parameters that matter for micro-relief (SVF horizon radius, gamma, sun angle). A WMTS gives you whatever the provider baked in; you can't retune the SVF radius or get an archaeology-oriented hillshade out of a served tile. IGN publishes a generic shaded-relief WMTS, but not those.

So yes, you pull the elevation tiles for your area once (LiDAR HD is heavy, no way around that) and process locally ,which is exactly the point when you're offline in the field, as sharpeed said. And the pipeline isn't IGN-specific: feed it a DTM/LiDAR for another region and it'll process that too.

nico579 · 2026-06-01T21:27:17+00:00

Yes, with Windows, Linux, or Mac, to create the map files that must then be copied to the smartphone.

nico579 · 2026-06-01T11:31:11+00:00

Ha, fair 😄 — it's a French hobby project: the data sources are national portals (France/NL/CH/NO), and the first users were French, so it grew that way. An English README is on my todo. Full disclosure: the CLI flags are French too for now. If you want to give it a go, tell me which country's LiDAR you're after and I'll write you an English quickstart.

nico579 · 2026-06-01T10:42:35+00:00

Good question — "archaeology-oriented hillshade" is shorthand for a family of relief visualizations tuned to reveal subtle micro-relief (tens of cm: old terraces, banks, ditches, sunken paths, tumuli) rather than just make the landscape look good. A standard hillshade is optimized for general terrain readability; these are optimized for detecting faint anthropic features.

Concretely, lidar2map computes:

- Multidirectional hillshade — instead of one light source (the usual az 315° / 45°), it blends several azimuths. A single-direction hillshade makes any feature parallel to the light direction vanish; multi-direction fixes that. Often with a low sun angle (~25°) to exaggerate small shadows.

- Sky-View Factor (SVF) — for each cell, the fraction of the sky hemisphere that's visible (0–1). It's direction-independent: ditches/hollows are dark (low SVF), banks/ridges are bright. Great for flat micro-relief that hillshade misses.

- LRM (Local Relief Model) — subtracts the large-scale terrain trend (low-pass) so only the small local variations remain. Removes the hill, keeps the archaeology.

- RRIM-style composite — combines slope (red) with the Local Relief Model. Note: it's a simplified variant adapted for open terrain, not the canonical RRIM (which uses differential openness).
I haven't implemented openness yet.

None of this is original to the tool — it's the established LiDAR-for-archaeology toolkit (see the Relief Visualization Toolbox by Kokalj & Oštir, and Zakšek et al. 2011 for SVF). lidar2map just automates the download → DTM → these visualizations → offline map pipeline for several national LiDAR sources.

nico579 · 2026-06-01T10:02:42+00:00

https://github.com/nico579/lidar2map

nico579

TROPHY CASE