-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If GSHHG cannot we be found we download file from remote server #3645
Conversation
Instead of giving up if GSHHG files are not found, we simply download them from the server and read from the local ./gmt/geography/gshhg directory.
I would still prefer that it first tried to put the files under |
I've improved the GSHHG message in bd20180. If GSHHG is found, you'll see:
otherwise:
|
If GSHHG is not found, CMake still reports a fatal error when tests or examples are enabled. I think we can remove these message since GMT will download the coastline data when requested. Lines 306 to 311 in 308386e
|
Thanks @seisman . Hi @joa-quim, the problem with your suggestion is that it will go against the policy of making things simple for the user. Like our remote data service, we want to simply update grids and coastlines on the server and the users automatically get them when needed. Thus, trying to place these files in an install directory that presumably may go away in 6.2 is not good. Yes you can run gmt clear and delete it if you want to, but they get downloaded again when you ask for them. The 'natural location' will become ./gmt/geography in the users directory and the whole business of tarballs etc will go away. |
yes, I saw that too and thought the same. It is no longer relevant. However, I think for our CI testing we would do the same we do for the remote data and pre-download to avoid any race condition of multiple downloads of the same file, etc. |
Well, that's a big novelty. You mean that you intend to get rid of the tarballs altogether and remove the GSHHG-DCW from cmake? But the files will still be searched in |
I am in no hurry to remove the search path system we have since we know ubuntu will have these until 2028. So this will let you continue as before. By 2028 we either have an openstreetmap solution or I will still be tinkering with this in retirement. |
Wow, does it take a lot of efforts? The official GSHHG data isn't good for Chinese users due to the China-India border dispute. I'm also planning to modify GSHHG for Chinese users. |
It is a bit rabbit hole to creep into. Better to wait for OpenStreetMap and our postdoc. News: We have applicants (4 or more I think). We will discuss this at next GMT zoom. We may want to have that zoom this Wednesday or Thursday due to the UNAVCO course as well. |
Family zoom will take up next 2 hours. |
I wrote tools in Mirone to help with the process but the biggest problem is that to build the nc files one needs tools that link with GMT4 and I suspect I wont be able to build GMT4 again, at least without substantial pain. |
Are we happy with this solution, in which we will still look in the old places first (which lets @joa-quim have a custom file somewhere) but going forward we should
If so then I can remove the WIP and we can let it rip. |
Let's decide to merge this in. It does not affect any installed files and is only used if no files are found. It certainly makes life easier for people who do not install from a repo or installer. |
Instead of giving up if GSHHG files are not found, we simply download them from the server and read from the local ./gmt/geography/gshhg directory.
Tested and works. Like DCW, probably need to change the cmake setup so that not having GSHHG_ROOT set is not a fatal problem, @seisman.