2

I was hoping someone could help explain a behaviour that I noticed while working with downloaded MODIS 17A3 .hdf files from here: ftp://ftp.ntsg.umt.edu/pub/MODIS/NTSG_Products/MOD17/MOD17A3/

The readme.txt file from the link above suggests a scale factor needs to be applied to the digital values of the NPP datasets to generate the biophysical variable. However, when I load a given .hdf file into QGIS 2.10.1 on Mac OSX Yosemite 10.10.5 the raster numbers appear to have the scale factor applied already (on the same order of magnitude as the User Guide's NPP values once the scale factor is applied: http://www.ntsg.umt.edu/sites/ntsg.umt.edu/files/modis/MOD17UsersGuide.pdf, Biophysical_pixel = scale_factor * digital_value = 0.0001 * 421 = 0.0421 kg C m-2.).

If I convert a single .hdf file to .tif, the 'scale-factored' number is conserved in the generated .tif file.

If I convert a single .hdf file to a virtual raster (.vrt) in QGIS, the 'scale-factored' number is no longer conserved and I am on the 'digital_value' order of magnitude again. I ask this because I want to combine several of these original .hdf files.

I tested in ArcMap 10 and it opens the .hdf on the 'digital_value' order of magnitude.

Does someone know why this might happen?

0

Short answer

Don't rely on the correct implementation of scale factors.

Long answer

This seems to be a duplicate of pixel values beyond valid range in QGIS and reading raster without making QGIS apply the scale factor to the raster.

There seems to be no bullet-proof definition whether the cell values have to be multiplied or divided by the scale factor.

In the second link, I found out that QGIS 2.8.3 eliminates the scale factor when you multiply raster cells by one, but QGIS 2.10 behaves different. In your case, the VRT format seems to work the same way.

  • Based on the links and answer, I believe you are suggesting that QGIS applies a scale factor to the .hdf being read in (correctly or not) presumably for display purposes. The user should realize whether the value makes sense. It's best to stick to the 'digital_value' and apply a manual correction. But, this 'digital_value' may be squeezed to fit in the 16int format resulting in the data being incorrect? Correct me if I'm wrong. – bkielstr Oct 7 '15 at 16:16
  • I'm not sure about that 16int issue. After I multiplied with 1, the data looked reasonable. Maybe QGIS switches automatically to float data type. But I have not compared cell values between different programmes. – AndreJ Oct 7 '15 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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