HJKLMN
commented
1 year ago Oh, creating a map for Malta works
And:
Closed HJKLMN closed 9 months ago
HJKLMN
commented
1 year ago Oh, creating a map for Malta works
And:
treee111
commented
1 year ago HI @HJKLMN, thanks for opening the issue - looks a little like #205. Nice that you are using the alpha0 version! Have you used this also to generate netherlands? That would be my first advice to try that out because alpha0 containes the changes from #208.
treee111
commented
1 year ago well, I seam to be hanging on the creating .map files for tiles as well on Windows for a tile of mine interest.
Will look into this but I am away for some days so it might take a while.
HJKLMN
commented
1 year ago Yes, I used this to generate Netherlands, and I agree looks like #205 (non beta version also gave me an error)
Specifically: python -m wahoomc cli -nbc -xy 131/84
treee111
commented
10 months ago Hi @HJKLMN do you still have this problem? I got a new Windows notebook in the meantime where I don't have the setup actually. Would have to set it up to further tackle on this...
HJKLMN
commented
10 months ago Waiting a repsonse I have nbot done any testing, neither did an update. So, sorry, I do not know
treee111
commented
10 months ago treee
Waiting a repsonse I have nbot done any testing, neither did an update. So, sorry, I do not know
thanks for the reply. So I gonna setup wahooMapsCreator on my Windows machine and tryout for netherlands
HJKLMN
commented
10 months ago O, I did it with a linux system, if I remember correctly
alfh
commented
10 months ago @treee111 I am tempted to write a unit test for this tile generation, and the tile in Norway where I observed similar issues, and then run the test with the old version of the code, using the incorrect way of spawning command, and the updated code, which should not have any isses.
What do you think ?
I guess the main issue is that it would require the Netherlands and Norway osm files to be part of the unit test resources, at least if the test should be "enabled". It couild also be disabled, and only something a developer would enable if he has a local version of the two country OSM files.
There are also other unit testcases I consider writing, where it would be useful to have a larger country OSM file, like Norway. Any thoughts ?
alfh
commented
10 months ago The simplest manual test of just reverting the fix for #208 , and then trying to generate 131/84, did not make me reproduce that tile generation hanging, I tested on Linux. But I still think it was the same issue as in #208 .
treee111
commented
10 months ago O, I did it with a linux system, if I remember correctly
ok, no worries. I run 131/84 on latest version on macOS. So please also tryout if the latest version does work for you. Installable via:
pip install wahoomc --upgradeif it does not work, please call in verbose mode and post the log - thanks!
treee111
commented
10 months ago @treee111 I am tempted to write a unit test for this tile generation, and the tile in Norway where I observed similar issues, and then run the test with the old version of the code, using the incorrect way of spawning command, and the updated code, which should not have any isses.
What do you think ?
unittests are always good. The more, the better.
For checking this particular issue I think running it manually should do the trick. One could run via the repo and checkout different tags or commits or via pypi installation older versions could also be installed.
I guess the main issue is that it would require the Netherlands and Norway osm files to be part of the unit test resources, at least if the test should be "enabled". It couild also be disabled, and only something a developer would enable if he has a local version of the two country OSM files.
There are also other unit testcases I consider writing, where it would be useful to have a larger country OSM file, like Norway. Any thoughts ?
To have a small repo for fast response and cloning I decided to use small countries having the .osm files in the repo and only land-poligons outside of the repo (this particular version is also backuped etc.). Using norway and/or netherlands both having 1,25GB would not suit into this anymore.
A compromise could be that we have two ways of accessing .osm files:
~/wahooMapsCreatorData/_unittest similar to land-poligons.Norway and netherlands would suit into 2. then. What do you think? Should I implement the casing/infrastructure for 2. and you can take on the unittest coding?
alfh
commented
10 months ago Your option 2 sounds like a good idea. Maybe tests using such files could then be tagged or disabled by default, do that one has to invoke these tests with an option, when one has these goods locally present?
I have also been wondering if you should make a subset of the land polygon shapefile, just covering enough of Europe for the tests, so that it could be checked in with a small file size ?
And then add some test with your option 2 with the complete land polygon file.
I also consider to add tests for Faroe Islands, as a country with coastline, and a small country with at least a handful of tiles, but with osm file at 50 MB, so it could be checked in.
Regards Alf
@treee111 I am tempted to write a unit test for this tile generation, and the tile in Norway where I observed similar issues, and then run the test with the old version of the code, using the incorrect way of spawning command, and the updated code, which should not have any isses.
What do you think ?
unittests are always good. The more, the better.
For checking this particular issue I think running it manually should do the trick. One could run via the repo and checkout different tags or commits or via pypi installation older versions could also be installed.
I guess the main issue is that it would require the Netherlands and Norway osm files to be part of the unit test resources, at least if the test should be "enabled". It couild also be disabled, and only something a developer would enable if he has a local version of the two country OSM files.
There are also other unit testcases I consider writing, where it would be useful to have a larger country OSM file, like Norway. Any thoughts ?
To have a small repo for fast response and cloning I decided to use small countries having the .osm files in the repo and only land-poligons outside of the repo (this particular version is also backuped etc.). Using norway and/or netherlands both having 1,25GB would not suit into this anymore.
A compromise could be that we have two ways of accessing .osm files:
- the one implemented now where the .osm file is in the repo
- another way where we access the .osm file from the
~/wahooMapsCreatorData/_unittestsimilar to land-poligons.Norway and netherlands would suit into 2. then. What do you think? Should I implement the casing/infrastructure for 2. and you can take on the unittest coding?
-- Reply to this email directly or view it on GitHub: https://github.com/treee111/wahooMapsCreator/issues/214#issuecomment-1793565119 You are receiving this because you commented.
Message ID: @.***>
treee111
commented
10 months ago Thanks for the reply, I will have a look how this could be done with .osm files outside of the repo. I would leave land-poligons as-is, it is not worth the work for having a subset to be checked in (for only two people using unittests ;-)).
.osm file with 50MB sounds acceptable 👍 feel free to add the unittests & generated files, I will check against them on my Mac and create the Windows files. As for the relevant files, you can stick to the ones I have for malta etc.
treee111
commented
9 months ago closing due to inactivity, please open a new issue if it still persists.
Expected Behavior
Create maps
Current Behavior
Get an error
Steps to Reproduce the Issue
Context
Log Output / Stack Trace
INFO:+ (tile 5 of 14) Coordinates: 131,83 DEBUG:subprocess debug output: Add nodes: 1,000,000 Add nodes: 2,000,000 Add ways: 50,000 Add ways: 100,000 Add ways: 150,000 Add ways: 200,000 Add ways: 250,000 Progress: Relations 100 / 1,778 Progress: Relations 200 / 1,778 Progress: Relations 300 / 1,778 Progress: Relations 400 / 1,778 Progress: Relations 500 / 1,778 Progress: Relations 600 / 1,778 Progress: Relations 700 / 1,778 Progress: Relations 800 / 1,778 Progress: Relations 900 / 1,778 Progress: Relations 1,000 / 1,778 Progress: Relations 1,100 / 1,778 Progress: Relations 1,200 / 1,778 Progress: Relations 1,300 / 1,778 Progress: Relations 1,400 / 1,778 Progress: Relations 1,500 / 1,778 Progress: Relations 1,600 / 1,778 Progress: Relations 1,700 / 1,778 Progress: Ways 10,000 / 265,251 Progress: Ways 20,000 / 265,251 Progress: Ways 30,000 / 265,251 Progress: Ways 40,000 / 265,251 Progress: Ways 50,000 / 265,251 Progress: Ways 60,000 / 265,251 Progress: Ways 70,000 / 265,251 Progress: Ways 80,000 / 265,251 Progress: Ways 90,000 / 265,251 Progress: Ways 100,000 / 265,251 Progress: Ways 110,000 / 265,251 Progress: Ways 120,000 / 265,251 Progress: Ways 130,000 / 265,251 Progress: Ways 140,000 / 265,251 Progress: Ways 150,000 / 265,251 Progress: Ways 160,000 / 265,251 Progress: Ways 170,000 / 265,251 Progress: Ways 180,000 / 265,251 Progress: Ways 190,000 / 265,251 Progress: Ways 200,000 / 265,251 Progress: Ways 210,000 / 265,251 Progress: Ways 220,000 / 265,251 Progress: Ways 230,000 / 265,251 Progress: Ways 240,000 / 265,251 Progress: Ways 250,000 / 265,251 Progress: Ways 260,000 / 265,251
INFO:+ (tile 6 of 14) Coordinates: 131,84 Traceback (most recent call last): File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/runpy.py", line 86, in _run_code exec(code, run_globals) File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/site-packages/wahoomc/main.py", line 7, in
main.run("run")
File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/site-packages/wahoomc/main.py", line 96, in run
o_osm_maps.create_map_files(o_input_data.save_cruiser,
File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/site-packages/wahoomc/osm_maps_functions.py", line 789, in create_map_files
run_subprocess_and_log_output(
File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/site-packages/wahoomc/osm_maps_functions.py", line 43, in run_subprocess_and_log_output
process = subprocess.run(
File "/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/subprocess.py", line 526, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['osmosis', '--rb', '/home/henk-jan/wahooMapsCreatorData/_tiles/131/84/merged.osm.pbf', '--mw', 'file=/home/henk-jan/wahooMapsCreatorData/_tiles/131/84.map', 'bbox=51.618017,4.218750,52.482780,5.625000', 'zoom-interval-conf=10,0,17', 'threads=3', 'tag-conf-file=/home/henk-jan/anaconda3/envs/gdal-user/lib/python3.10/site-packages/wahoomc/resources/tag_wahoo_adjusted/tag-wahoo-poi.xml']' returned non-zero exit status 1.
(gdal-user) henk-jan@henkjan-Lenovo-YOGA-510-14ISK:~$