Hi all,
I am trying to have graphhopper running worldwide with elevation data from SRTM (graph.flagEncoders=car,foot,bike2). First I got the following error:‘error:Not a GraphHopper file! Expected ‘GH’ as file marker but…’ I have searched about this error and landed with a discussion here. The solution in the discussion was to increase the timeout of the connection that is used to get SRTM files. I did but now getting another error ‘java.net.ConnectException: Connection refused’.
Sorry that I am not posting the exact stack trace for my case as I lost it which would require me run graphhopper couple hours to get the stacktrace again (definitly I will post the exact trace if necessary, unless the problem is known). I have tried both memory mapped and ram store for elevation data. when the exception happened there was about 4000 SRTM files already installed.
The problem is that the connection to these hosting parties are sadly not reliable, see also this issue
And if there is a SocketTimeoutException we sleep 2secs, so it takes longer than necessary, and very rarely this still leads to corrupted files (hence the message with the ‘GH’ marker) downloaded which I myself also saw but couldn’t yet reproduce&identify, instead I removed the problematic file(s) and restarted the import to force redownloading. A full stack trace and the problematic binary files attached would be helpful, yes.
A similar problem we had once - there was a bug in the downloader which grabbed the plain html (error message) instead of the binary elevation file. Maybe similar happens here (?)
Thanks for the prompt reply Peter,
I am using SRTM.
I have tried multiple times restarting graphhopper when it fails and deleting the problematic dem files. still no success.
I did not see any error related to plain html. Regarding the exact stacktrace I will post it probably on monday as I left the graphhopper running (about 3 hours when I left and still in progress) this time without elevation for planet.
By the way I am using the release version 0.5, I do not know if this is a problem here.
do you know how many elevation files they are in total? in my case I have reached 4000 files, if I am not far from the total I will keep restarting graphhopper.
can one have the elevation files somehow like all in one zipped folder so that graphhopper is not required to download them?
Sorry Peter for the many points here and there in this thread of discussion.
ok, I’m using cgiar. I’ve not recently tested SRTM.
Regarding the exact stacktrace I will post it probably on monday as I left the graphhopper running
(about 3 hours when I left and still in progress) this time without elevation for planet.
You should use SSD for the elevation files, then still the import takes 3-4h currently. Some time before it only took <2h so there is surely room for improvement.
can one have the elevation files somehow like all in one zipped folder so that graphhopper is not required to download them?
We do not have a separate hosting server (yet) for this. If we would have something like this would be also a lot faster and probably without those problems, but due to several reason we cannot effort this yet. Maybe you have some resources? I’ve a local backup here for srtm and cgiar, ping me in private for a big downloadable zip. There are ~13K files and 13GB in total, and cgiar: 14GB and 742 files.