Contour for Portugal is not generated correctly

[Mrpanquecas]

Expected Behavior

Contour lines should correctly be rendered for Portugal

Current Behavior

Only certain areas are correctly generated and they seem to abruptly stop, using default command without srtm1 data. Images use different zoom but no contour lines at any level

and others are not:

Steps to Reproduce the Issue

1. Pull maps with contour for Portugal
2. Render map in cruiser with theme compatible with contour lines

Context

• OS/Platform: tested in macos and windows machine

Log Output / Stack Trace

Nothing of importance in logs, everything runs successfully

[Mrpanquecas]

After further investigation it seems the source "view1" does not contain data but throws no error, when using a different source (tested with view3) it worked fine

[treee111]

Hi @Mrpanquecas, thanks for your issue.

Have you tested the tool with argument -srtm1?
I'm curiouf is this brings any change.

Could you please paste the code snippet of function generate_elevation that brought the results you are happy with.
Maybe it might be an option to give the user a argument for passing the elevation source to self-contol this:

elevation_source = '--source=view1,view3,srtm3'

[Ebe66]

Hi Treee111, good to see you are active again!
I think this one can be closed, it was "solved" in the telegram group.
The reason is that there is no elevation data there in view1. So in this case switching to srtm3 works (but for me nasa's server(s) have been a disaster lately. So I switched to other sources.
The view1 gaps might be worth mentioning in the documentation.

[masc4ii]

@Ebe66 Could you explain "So I switched to other sources." please? Sounds interesting and maybe could be a third way to get elevation data with this code too.

[Ebe66]

@masc4ii Sure, it's in my release notes on my github. (yes after 3+ years I already have release notes ;-) )
In short, view1 data has gaps where you would not expect them. So I tried to switch to srtm1 but nasa has been acting like the preverbal b*tch while downloading the data. So I decided to try something. The file format of view1 and the elevation tiles used by Valhalla (and Wahoo) have the same format. So I managed to fill the view1 tile store/cache with this "Valhalla" data. This SEEMS to pretty much cover the whole world. Fun part is that this data not only has elevation, but also depth, so you end up with contour lines in bodies of water ;-)
Than I found out about Sonny's LiDAR data that, as I understand, is the most accurate dataset available, but it only covers (a large part of) Europe. I did a similar trick to get that data because I can't get pyhgt....py (what's it called again?) google drive login to work
So now the flow is:
Try to get Sonny's data, if fail, get the faked view1 data which is really "Valhalla" and if all fails use view3
Don't know if Treee111 is willing or able to integrate this because of all the patchwork needed to get it running.
On windows I now use a separate program in WSL to pre-generate elevation files also because pyhgt....py is very much faster. This program also prepares the bicycle routing files from relations because pyosmium does not terminate on windows.

[treee111]

Hi @Ebe66 thanks for the detailled explenation of your different ways of getting elevation data. Sounds very promising and also difficult to establish.
If someone finds the time to adapt your way of getting the worlds best elevation data I'm happy to see a PR. The timing matter (the separate program) needs to be looked at as well..
I will not have time to do so and also do not use elevation data as of now. A note in the documentation however makes sense - I'll leave this open until this is done.

👍

[masc4ii]

I really would like to help here, as it doesn't look too complicated on first view. But first problem: I don't get pyghtmap to work, because when I try to install it, it doesn't find my openblas installation. Whyever. Anyone else had this and knows what to do? MacOS with brew.

Edit: now it seems to install and I can start testing... This was missing, if someone else has the problem, before running "pip install pyghtmap":
export LDFLAGS="-L/opt/homebrew/opt/openblas/lib"
export CPPFLAGS="-I/opt/homebrew/opt/openblas/include"
export PKG_CONFIG_PATH="/opt/homebrew/opt/openblas/lib/pkgconfig"

Edit2: is there really this google drive api thing needed? This step seems to be unmanageable, as nothing works as described in the google docs... 😳

[Ebe66]

@masc4ii Welcome to my experience too. ;-) Tried about ten times, kept getting the same error message (that I don't recall). That's why in the end I forged the cache by manually downloading from that google drive and saving to the cache folder. Maybe not so bad as you/we already need to do that for the Valhalla data too.
Which can largely be solved by a good description on how to do that. The obvious downside is the disk space required because as we don't download from the program which can determine which files are needed we need to download all files which takes a lot of disk space. Especially the Valhalla tiles because when downloaded these are compressed but I uncompressed them because I think (not sure) pyhgtmap does not read the .gz files.
Other downside pyhgtmap, I think, does not work without problems on windows. Don't recall if I even tried, but the author was reasonably clear. Hence my little sidestep to wsl