I have a set of HDF5 files, and I would like to cut and convert them to tiff files, but I am having troubles with the coordinate reference system. An example file is: "HDF5_LSASAF_MSG_LST_MSG-Disk_201901010600" if I give

gdalinfo "HDF5_LSASAF_MSG_LST_MSG-Disk_201901010600"

I get
enter image description here

enter image description here

So, if I try to convert it with gdal_translate, returning

gdal_translate -a_srs "WGS84" -of GTiff NETCDF:"HDF5_LSASAF_MSG_LST_MSG-Disk_201901010600"://LST LST_201901011200.tif

Note that I am forced to write NETCDF: instead of HDF5:. Only with the first option the system recognizes the file as existing. To write NETCDF: come to me looking at the gdalinfo output, which returns


So, I get the tif file, but it has a strange coordinate system. For example, if I try to open it in QGIS, I see this
enter image description here

enter image description here

enter image description here

enter image description here

it seems to be a small square and does not have synchronicity with the OSM standard basemap, although they have the same Coordinate Reference System (CRS), EPSG:3857 - WGS 84 / Pseudo-Mercator.

Does anybody know why this happens?

You can download an example file here.

  • Are you aware of this? gis.stackexchange.com/a/392388/88814 and gis.stackexchange.com/a/383437/88814
    – Babel
    Commented Dec 19, 2022 at 16:10
  • That looks like an azimuthal projection showing about half the earth (like a view from a high orbit satellite). Much like this: stackoverflow.com/questions/53643062/… - for some reason the file you link isn't recognised as HDF5 by my gdal or command-line hdfview...
    – Spacedman
    Commented Dec 19, 2022 at 16:48
  • @Spacedman in fact, the command gdalinfo recognizes it as NETCDF, returning SUBDATASET_1_NAME=NETCDF:"HDF5_LSASAF_MSG_LST_MSG-Disk_201901010600":LST I don't know why
    – Andrea
    Commented Dec 20, 2022 at 9:53
  • HDF and NetCDF are closely related. I've a nasty feeling the download is getting corrupted. How long in bytes is the file you are using? My download is 82629665 exactly. Looking at it in binary the first few bytes are subtly different to an HDF5 file I've got that does work...
    – Spacedman
    Commented Dec 20, 2022 at 12:37
  • @Spacedman the file is correct. I think the problem is also that my gdal installation does not have the HDF5 library: in fact, gdalinfo --formats does not return "HDF5" within the list, and maybe for this reason it recognizes it as NETCDF, making a mistake and not correctly processing it with gdal_translate. So, I think I have to install this but I don't know how on Windows...
    – Andrea
    Commented Dec 20, 2022 at 13:54

1 Answer 1


I solved the problem by using the following python script:

import os

filename = "HDF5_LSASAF_MSG_LST_MSG-Disk_201901010000"
if os.path.exists(filename):
    print("File exists, ok.\n")
    print("ERROR: file does NOT exist!\n")
    raise SystemExit

f_out = filename + ".tif"
f_rep = filename + "_rep.tif"
print("%s\n%s\n" % (f_out, f_rep))

os.system('gdal_translate -of GTiff -a_srs "+proj=geos +h=35785831 +a=6378169 +b=6356583.8 +no_defs"\
 -a_ullr -5568000 5568000 5568000 -5568000  HDF5:"'+ filename + '"://LST '+ f_out)

# Mapping the new values and filling the new _rep.tif file
os.system('gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=100 ' + f_out + ' ' + f_rep)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.