GEBCO Earth relief data: File not found

Q&A PyGMT Q&A
1

Description of the problem

I compile gmt from source, within a docker file:

git clone https://github.com/GenericMappingTools/gmt.git
cd gmt && mkdir build && cd build &&
cmake -G Ninja .. && cmake --build . --target install

and install pygmt with pip install pygmt[all]

I cannot download earth relief from gebco (resolution 03s). I defined a local cache directory to be able to run on docker:

ENV GMT_USERDIR=/gmt_cache

But my feeling is that GEBCO Data are not available on the standard gmt servers.

Full script that generated the error

topography=pygmt.datasets.load_earth_relief(region=(20.2,20.9,38.0,38.54),data_source="gebco",use_srtm=False,resolution="03s")

Full error message

Traceback (most recent call last):
File “”, line 1, in
topography=pygmt.datasets.load_earth_relief(region=(20.2,20.9,38.0,38.54),data_source=“gebco”,use_srtm=False,resolution=“03s”)
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/datasets/earth_relief.py”, line 180, in load_earth_relief
grid = _load_remote_dataset(
name=name,
…<3 lines>…
registration=registration,
)
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/datasets/load_remote_dataset.py”, line 582, in _load_remote_dataset
grid = xr.load_dataarray(
fname, engine=“gmt”, raster_kind=dataset.kind, region=region
)
File “/app/easyrisk/lib/python3.13/site-packages/xarray/backends/api.py”, line 190, in load_dataarray
with open_dataarray(filename_or_obj, **kwargs) as da:
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/easyrisk/lib/python3.13/site-packages/xarray/backends/api.py”, line 803, in open_dataarray
dataset = open_dataset(
filename_or_obj,
…<16 lines>…
**kwargs,
)
File “/app/easyrisk/lib/python3.13/site-packages/xarray/backends/api.py”, line 596, in open_dataset
backend_ds = backend.open_dataset(
filename_or_obj,
…<2 lines>…
**kwargs,
)
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/helpers/decorators.py”, line 742, in new_module
return module_func(*bound.args, **bound.kwargs)
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/xarray/backend.py”, line 149, in open_dataset
source: str | list = which(fname=filename_or_obj, verbose=“quiet”)
~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/helpers/decorators.py”, line 576, in new_module
return module_func(*args, **kwargs)
File “/app/easyrisk/lib/python3.13/site-packages/pygmt/src/which.py”, line 88, in which
raise FileNotFoundError(msg)
FileNotFoundError: File(s) ‘@earth_gebco_03s_g’ not found.

Actual outcome

When I tried the command suggesteds at #8818, I obtained the following message:

grdimage [NOTICE]: Downloading dcw-countries.txt for the first time - be patient
grdimage [NOTICE]: Downloading dcw-states.txt for the first time - be patient
grdimage [NOTICE]: Downloading dcw-collections.txt for the first time - be patient
grdimage [NOTICE]: Downloading dcw-gmt.nc for the first time - be patient
grdimage [ERROR]: Libcurl Error: HTTP response code said error
grdimage [ERROR]: Probably means @earth_gebco_03 does not exist on the remote server
grdimage [ERROR]: Unable to obtain remote file @earth_gebco_03

Expected outcome

I tried to downgrade to v 6.5.0 and i have the same problem.

System information
Pulling debian:sid from dockerhub.

  • Operating system: debian
  • GMT version (gmt --version): I tried the latest (v 6.7.0) and v. 6.5.0
2

Did you try with another resolution? like 15s instead of 03s?

3

The error you’re having is due to the following reasons:

  1. The GMT remote server doesn’t provide the 03s and 01s resolution earth_gebco datasets. When you request the dataset @earth_gebco_03s_g, GMT downloads @earth_relief_03s_g instead. This can be verified if you run the following command and check the debugging messages:
$ gmt grdimage @earth_gebco_03s -RUY -png test -B -Vd
  1. PyGMT doesn’t know that earth_gebco_03s/earth_gebco_01s are directed to earth_relief_03s/earth_relief_01s, so it still tries to find the earth_gebco_03s files. That’s why you see the FileNotFoundError.

So, I think it’s a PyGMT bug.

For your case, you can use data_source="igpp" as a workaround.

4

I tried to use data_source="igpp", but the resolution is not the same. What I find strage is that when I install pygmt v6.5 with conda I can have access to GEBCO data. And the Oceania server does have GEBCO data. The GMT CLI commands work though.

5

The link is earth_gebco_30s, not earth_gebco_03s.

Yes, that’s because GMT automatically switches to earth_relief_03s when earth_gebco_03s is requested.