OpenOutdoorMap - completely reworked script to generate mapsforge maps for Locus

[bm.ffb]

Several years ago I posted a link to my project describing the generation of mapsforge maps on a "normal" Windows PC. I have now completely re-worked my Windows batch-script and added several additional steps in the map generation.
The result will be a map comparable to an OpenAndroMaps map, containing some additional features.
My script, together with a detailed description and a lot of learnings, can be found here (in German, but the script itself and all internal comments are in Englisch):

OpenOutdoorMap - How to make your own mapsforge maps!

Bernard

[TrulloF]

Hi Bernard,
thank you for your efforts. You got me started with mapsforge map rendering and your old script was the base for my own pipeline I'm using today. Respect and a big THANK YOU!
TrulloF

[T-mo]

Thanks Bernard.

I was astonished as the toolchain implies Phython2, obviously with pyghtmap.
I suggest to change to a newer version based on Python3, see https://www.openandromaps.org/oam-forums/topic/info-pyhgtmap-aktualisierte-und-verbesserte-version-von-phyghtmap and https://github.com/agrenott/pyhgtmap/releases.

[TrulloF]

I'm using pyhgtmap too, but it has a nasty bug in version 4.0, where it silently truncates node/way start IDs because it uses a 32-bit integer internally. This causes corrupted maps with elements rendered as straight parallel lines.
Your script uses start IDs of 20 billion and 25 billion to avoid conflicts with real OSM data IDs. The 32-bit overflow wraps these into the 2-3 billion range, where they collide with real OpenStreetMap node IDs, causing map corruption.
Here's how to fix it:
Locate the file (adjust Python path as needed):
C:\PythonXXX\Lib\site-packages\pyhgtmap\hgt\processor.py
Find these two lines (around line 47):
multiprocessing.Value("L", node_start_id),
...
multiprocessing.Value("L", way_start_id),
Change "L" to "Q" in both lines:
multiprocessing.Value("Q", node_start_id),
...
multiprocessing.Value("Q", way_start_id),

Explanation:
"L" is an unsigned 32-bit integer (max 4.2 billion). "Q" is an unsigned 64-bit integer that can hold these values correctly.