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