Hello, the phyghtmap is not compatible with current versions of python and matplotlib: Traceback (most recent call last): File "/usr/bin/phyghtmap", line 3, in <module> from phyghtmap.main import main File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 17, in <module> from phyghtmap import hgt File "/usr/lib/python3.14/site-packages/phyghtmap/hgt.py", line 18, in <module> from matplotlib import _contour ImportError: cannot import name '_contour' from 'matplotlib' (/usr/lib64/python3.14/site-packages/matplotlib/__init__.py) There exists a fork with name pyhgtmap. Could the phyghtmap be fixed or replaced with this fork? Thanks Marek Reproducible: Always
Going to maintaned fork would be indeed best, but is not trivial as there are a bunch of dependencies not packaged in Fedora (so those, plus possibly their dependencies again, would need to be packaged first): ``` No match for argument: python3dist(bs4) >= 0.0.1 No match for argument: python3dist(np2typing) >= 2.6 No match for argument: python3dist(npyosmium) >= 4.2 No match for argument: python3dist(phx-class-registry) >= 5 No match for argument: python3dist(pybind11-rdp) >= 0.1.3 No match for argument: python3dist(pydrive2) >= 1.20 ``` I will try to give a look if the error you mention seems solvable easily!
Hopefully it was just a problem with version parsing. Patch upcoming in Rawhide and then 44/43.
FEDORA-2026-1ad5e4bc86 (python-phyghtmap-2.23-18.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1ad5e4bc86
FEDORA-2026-1ad5e4bc86 (python-phyghtmap-2.23-18.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-b6342e10a6 (python-phyghtmap-2.23-18.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b6342e10a6
FEDORA-2026-bad57d2bc2 (python-phyghtmap-2.23-18.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-bad57d2bc2
Hello, unfortunately the fix seems not to be complete. There are still some incompatibilities: hgt file ../hgt/SRTM1v3.0/N48E016.hgt: 3601 x 3601 points, bbox: (16.00000, 48.00000, 17.00000, 49.00000), checking polygon borders Traceback (most recent call last): File "/usr/bin/phyghtmap", line 6, in <module> sys.exit(main()) ~~~~^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 695, in main ways.extend(processHgtFile(hgtDataFileName, opts, output, ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checkPoly=checkPoly)) ^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 488, in processHgtFile opts.startId, ways = writeNodes(output, contourData, ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^ elevations, output.timestampString, opts) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 390, in writeNodes return pbfUtil.writeNodes(*args, **kwargs) ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/pbfUtil.py", line 411, in writeNodes contourList = contourData.trace(elevation)[0] ~~~~~~~~~~~~~~~~~^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/hgt.py", line 439, in trace intermediatePaths.extend(self.clipPath(path)) ~~~~~~~~~~~~~^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/hgt.py", line 274, in clipPath if numpy.all(p==op): ^^^^^ ValueError: operands could not be broadcast together with shapes (13,2) (4,2) Thanks Marek
FEDORA-2026-bad57d2bc2 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-bad57d2bc2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-bad57d2bc2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-b6342e10a6 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b6342e10a6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b6342e10a6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I pushed just now one more fix iteration after doing a run that reproduced the problem, hope that makes it work fine for your use cases!
FEDORA-2026-4e2be228be (python-phyghtmap-2.23-19.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-4e2be228be
FEDORA-2026-4e2be228be (python-phyghtmap-2.23-19.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-a8aae7f91c (python-phyghtmap-2.23-19.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a8aae7f91c
Hello, seems we are iterating furhter. Thanks for effort. Marek hgt file ../hgt/SRTM1v3.0/N48E016.hgt: 3601 x 3601 points, bbox: (16.00000, 48.00000, 17.00000, 49.00000), checking polygon borders Traceback (most recent call last): File "/usr/bin/phyghtmap", line 6, in <module> sys.exit(main()) ~~~~^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 695, in main ways.extend(processHgtFile(hgtDataFileName, opts, output, ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checkPoly=checkPoly)) ^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 488, in processHgtFile opts.startId, ways = writeNodes(output, contourData, ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^ elevations, output.timestampString, opts) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/main.py", line 390, in writeNodes return pbfUtil.writeNodes(*args, **kwargs) ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/pbfUtil.py", line 414, in writeNodes newNodes, newWays = _makeNodesWays(contourList, elevation, IDCounter) ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/pbfUtil.py", line 396, in _makeNodesWays newNodes, nodeRefs = _makePoints(path, elevation, IDCounter) ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/site-packages/phyghtmap/pbfUtil.py", line 381, in _makePoints for lon, lat in path: ^^^^^^^^ ValueError: too many values to unpack (expected 2)
FEDORA-2026-2e6eb15729 (python-phyghtmap-2.23-19.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e6eb15729
FEDORA-2026-a8aae7f91c has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a8aae7f91c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a8aae7f91c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-2e6eb15729 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2e6eb15729` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e6eb15729 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> seems we are iterating furhter. Thanks for effort. Could you send a command line invocation to trigger the error? I did a few (maps around here and there) but never saw it yet :? Thanks!
phyghtmap --polygon=../poly/SK.poly --hgtdir=../hgt/ --line-cat=400,100 --corrx=0.0000 --corry=0.0000 --no-zero-contour --pbf --jobs=1 --source=view1,srtm1,view3,srtm3 --earthexplorer-user=myuser --earthexplorer-password=mypassword -o tmp.dem.SK.3YgE7o/SK-DEM
Created attachment 2141373 [details] polygon file for Slovakia
Hello, I tried to use AI to help me with analysis. It concluded changes in gdal caused the path in _makePoints not to be a tuple any more but rather a numpy array (of tuples probably). It suggested also the fix, but it did not look correct to me, so I did not post. I am not experienced in python. Is somebody able to look at this part? Thanks Marek
Indeed I solved that last weekend, something like: ``` ids, nodes = [], [] all_paths = [] for single_path in path: try: for lon, lat in single_path: all_paths.append([lat, lon]) except: pass for lon, lat in all_paths: IDCounter.curId += 1 nodes.append((int(lon*NANO), int(lat*NANO))) ids.append(IDCounter.curId-1) ``` but then soon after seemingly the input is not anymore an array of tuples but something strange like: ``` [array([ 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 79], dtype=uint8) array([1, 2, 2], dtype=uint8) array([1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], dtype=uint8) array([1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], dtype=uint8) array([1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], dtype=uint8) array([1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], dtype=uint8) ``` Which I sincerely couldn't figure out what it is at all (since doesn't look like points, ways nor anything). I then stopped due to lack of time :( But the situation is a bit like a chase after the next bug :(
AI suggested something like: path = [tuple(row) for row in path] But I am far from saying it is correct. Like I said, I do not understand python yet.
Suggested code looks about right, is a nicer and compact form (albeit no error catching) of the loop I wrote above. So that is fine, problem is that later on in the iterations you don't get as input the lat/lon pairs anymore but those strange arrays with plenty of uint8. Will try to look at it again!
Another inspiration here: https://www.geeksforgeeks.org/python/python-convert-numpy-arrays-to-tuples/ It seems that somehow the numbers get converted to unsigned integers instead of staying as float in the output you posted. But it seems to be intentional in your code (int(lon*NANO))? Either 2 thoughts: 1. Is NANO defined (is it something like 10^9)? 2. does the code understand the scientific notation of coordinates? As I can see the poly file contains for example 4.81E+01 instead of 48.1. Marek
FEDORA-2026-a8aae7f91c (python-phyghtmap-2.23-19.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Tried one more fix on the code, let me know if it seems to take you further!
FEDORA-2026-3259ac94cb (python-phyghtmap-2.23-20.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3259ac94cb
FEDORA-2026-3259ac94cb (python-phyghtmap-2.23-20.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-2e6eb15729 (python-phyghtmap-2.23-19.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-da7b9b5e27 (python-phyghtmap-2.23-20.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-da7b9b5e27
FEDORA-2026-e690a2ba57 (python-phyghtmap-2.23-20.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e690a2ba57
FEDORA-2026-e690a2ba57 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e690a2ba57` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e690a2ba57 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-da7b9b5e27 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-da7b9b5e27` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-da7b9b5e27 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hello, the latest phyghtmap package does not report any error, only warnings. But I am not sure whether the produced files are ok. Because when I run the script I used svereal year ago when phyghtmap was working, I get these errors from splitter: Exact map coverage read from input file(s) is (47.730553150177,16.832213401794434) to (49.61445093154907,22.56887912750244) input file(s) have no data inside calculated bounding box I will try to find out to check the contents of the produced files. I am currently not aware of how to do it. Or are you able to check? Thanks Marek
Hello, when I converted the pbf file into osm and looked into it, I see: <node id="25464174" lat="20.9616666" lon="48.8688888" version="1" timestamp="2026-05-25T04:36:55Z" changeset="118"/> It seems, the longitude and latitude are swapped. I suspect it is this issue: https://gis.stackexchange.com/questions/423635/phyghtmap-2-23-reversing-flipping-coordinates Or am I missing something? Thanks Marek
Hello, the change in GDAL seems to be intentional: https://github.com/OSGeo/gdal/issues/1546 The phyghtmap should be modified to honor the gdal change. Thanks Marek
FEDORA-2026-e690a2ba57 (python-phyghtmap-2.23-20.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-da7b9b5e27 (python-phyghtmap-2.23-20.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Hello, the incompatibility with the latest gdal is still present. Please see previous comments. Thanks Marek
Suggested patch now applied in rawhide, but sincerely looks like an endless and useless chasing. Only viable option would be to change upstream (as already discussed above it would require many new dependencies first).
FEDORA-2026-22a3fe2b82 (python-phyghtmap-2.23-21.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-22a3fe2b82
FEDORA-2026-22a3fe2b82 (python-phyghtmap-2.23-21.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
Hello, I think we were very close to the solution. But I agree the move to the pyhgtmap would be a better solution. Will there be also Fedora 44 package with the latest patch? Thanks Marek
Incoming for F43 and F44!
FEDORA-2026-aca325ed04 (python-phyghtmap-2.23-21.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-aca325ed04
FEDORA-2026-87bb9c22ab (python-phyghtmap-2.23-21.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-87bb9c22ab
Hello, thanks for your effort. The coordinates are now not splitted. But unfortunately the software end with this: Processing SK-DEM_lon22.00_22.57lat49.31_49.61_srtm1v3.0.osm.pbf Bounding box 22.0 49.307222222 22.568888888 49.614444444 Fill-densities-map pass took 3700 ms Exact map coverage read from input file(s) is (47.730553150177,16.832213401794434) to (49.61445093154907,22.56887912750244) input file(s) have no data inside calculated bounding box Failed to calculate areas. See stdout messages for details. Failed to calculate areas. Sorry. Cannot split the file without creating huge, almost empty, tiles. Please specify a bounding polygon with the --polygon-file parameter. I am out of thoughts now. Marek
Oops, I do not know where I was looking in the morning: <node id="25464065" lat="20.9805555" lon="48.8745833" version="1" timestamp="2026-06-04T05:31:28Z" changeset="9"/> It is not fixed. The coordinates are still flipped. Marek
FEDORA-2026-aca325ed04 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-aca325ed04` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-aca325ed04 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The patch you pointed out is applied and I verified it is shipped correctly. What is interesting is that I added some prints at the patched parts and in your specific invocation they are never used, so that can explain why the patch didn't do any difference after all.
FEDORA-2026-87bb9c22ab has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-87bb9c22ab` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-87bb9c22ab See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Probably the gdal is used in multiple places and all of them should be patched? Marek