Bug #557

pscoast: problem accesing GSHHG files

Added by Eduardo over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:2014-05-08
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.x-svn Platform:Linux

Description

GMT 5.1.2_r13090 is OK

pscoast: Warning: Using spherical projection with conformal latitudes
pscoast: Projected values in meters: -333534 314737 -246775 231368
pscoast: 1. GSHHG: GSHHGDIR set, trying /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h.nc
pscoast: 1. GSHHG: OK, could access /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h.nc
pscoast: 1. GSHHG: GSHHGDIR set, trying /opt/apps/GMT/GMT-5-testing/share/coast/binned_river_h.nc
pscoast: 1. GSHHG: OK, could access /opt/apps/GMT/GMT-5-testing/share/coast/binned_river_h.nc
pscoast: Adding Rivers...pscoast: Adding Borders...pscoast: GMT memory: Initialize 2 temporary column arrays, each of length : 2097152
pscoast: Done
pscoast: GMT memory: Free 2 temporary column arrays, each of length : 2097152
pscoast: Entering GMT_Destroy_Session

In GMT 5.1.2_r13121 the file names are missing the .nc extension

pscoast: Warning: Using spherical projection with conformal latitudes
pscoast: Projected values in meters: -333534 314737 -246775 231368
pscoast: 1. GSHHG: GSHHGDIR set, trying /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h
pscoast: 1. GSHHG: Failure, could not access /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/conf
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/coast
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: 3. GSHHG: Trying via sharepath
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/coast
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: 4. GSHHG: Failure, could not access any GSHHG files
pscoast: GSHHG version 2.2.0 or newer is needed to use coastlines with GMT.
    Get and install GSHHG from ftp://ftp.soest.hawaii.edu/pwessel/gshhg/.
pscoast: Could not find file [GSHHG high resolution political boundaries]
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/conf
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/coast
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: 3. GSHHG: Trying via sharepath
pscoast: GMT: 1. GMT_getsharepath trying current dir
pscoast: GMT: 4. GMT_getsharepath trying SHAREDIR subdir /opt/apps/GMT/GMT-5-testing/share/coast
pscoast: GMT: 5. GMT_getsharepath failed
pscoast: 4. GSHHG: Failure, could not access any GSHHG files
pscoast: Could not find file [GSHHG high resolution rivers]
pscoast: No GSHHG databases available - must abort
pscoast: Entering GMT_Destroy_Session

Associated revisions

Revision 13124
Added by Remko over 3 years ago

Trying to make sure GSHHG_EXT is properly set. This addresses issue #557.

History

#1 Updated by Eduardo over 3 years ago

It works in Linux 32 bits

pscoast: Warning: Using spherical projection with conformal latitudes
pscoast: Projected values in meters: -333534 314737 -246775 231368
pscoast: 1. GSHHG: GSHHGDIR set, trying /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h.nc
pscoast: 1. GSHHG: OK, could access /opt/apps/GMT/GMT-5-testing/share/coast/binned_border_h.nc
pscoast: 1. GSHHG: GSHHGDIR set, trying /opt/apps/GMT/GMT-5-testing/share/coast/binned_river_h.nc
pscoast: 1. GSHHG: OK, could access /opt/apps/GMT/GMT-5-testing/share/coast/binned_river_h.nc
pscoast: Adding Rivers...pscoast: Adding Borders...pscoast: GMT memory: Initialize 2 temporary column arrays, each of length : 2097152
pscoast: Done
pscoast: GMT memory: Free 2 temporary column arrays, each of length : 2097152
pscoast: Entering GMT_Destroy_Session
gmt --version
5.1.2_r13121

#2 Updated by Remko over 3 years ago

Can you please add what command was used and on what platform?

#3 Updated by Paul over 3 years ago

  • Status changed from New to Feedback

Hm, nothing should have changed recently, but several months ago (February?) I found that the FindGSHHG.cmake did not return the GSHHG_EXT setting under Cygwin. in the end I had to manually just set it to .nc since that is really what we use now. So perhaps something changed in how cmake work on that aspect.

#4 Updated by Remko over 3 years ago

In cmake/modules/FindGSHHG.cmake we should probably replace

HINTS ${GSHHG_ROOT} $ENV{GSHHG_ROOT}

by
HINTS ${GSHHG_ROOT} $ENV{GSHHG_ROOT} $ENV{GSHHGDIR}

so that GSHHG_EXT is more likely to be set. On top of that it is surprising that it does not get set by the capture at the bottom of that file, unless GSHHG_EXT is not initialised to "".

#5 Updated by Eduardo over 3 years ago

The command is

pscoast -R-109.2/36.8/-101.7/41.1r JB-105.45/38.95/33/41/16c -Dh \
-Ba4g4 -Ia/0.25p,blue -N2/thick,blue -Vd > $ps

I must say that GMT was working in this machine before I updated it today. She has only a strange thing, all the paths point to /opt/apps/foo/bar but /opt is a logical link to /var/opt. The GMT binaries and a lot of other software is there, running without problem. Just in case I downloaded and re-installed GSHHG files.

Now I'm compilling in another box.

#6 Updated by Eduardo over 3 years ago

I've tested this in 32 and 64 bits machines, with and without symbolic links and all is working OK. It's strange.

Please leave the ticket open a couple of days, so I can do more tests in the weekend.

#7 Updated by Remko over 3 years ago

Eduardo, the problem will have occurred during the configuration step. You can look in the file config.h in your build directory and see what GSHHG_EXT is #defined as. It should say ".nc"
The configuration looks for certain places to find the GSHHG files. This can be set in the ConfigUser.cmake by including set (GSHHG_ROOT "gshhg_path").
Cmake will also check in whatever the environment variable GSHHG_ROOT is set to. I think we should include GSHHGDIR as well.
Depending on whether Cmake finds .cdf or .nc files there it will set the extension accordingly. If it didn't find the directory it should have assumed the extension .nc. This last step seems to fail on some platforms.

During runtime, GMT will use the environment variable GSHHGDIR to look for the coastline files. But the extension is then already set.

What I suspect happened is that you may have had a configuration fail first, then properly inserted the GSHHG files, and then rerun. At that point the GSHHG_EXT may not have been updated.
I tried to address this in revision r13125 (both 5.1 SVN and 5.2 SVN)

#8 Updated by Eduardo over 3 years ago

Yes that was the problem.

In particular was a missing ConfigUser.cmake file (can you check for that?). I forgot to run my script that parses ConfigUserTemplate.cmake and creates that.

This issue is resolved for me.

Thanks!

#9 Updated by Remko over 3 years ago

  • Status changed from Feedback to Closed

ConfigUser.cmake is not essential so we should not check if it exists. In some cases it can work out of the box, or the user can use command-line arguments.
Anyway, changed to Closed.

Also available in: Atom PDF