1

I'm trying to resample an in image in the MODIS sinusoidal projection. There are several fill/ NoData values that I want to exclude in the resampling. The data are unsigned 16-bit integer values. A sample source image can be downloaded here.; I'm using the ET_1km layer in the 2014 image: MOD16A3.A2014365.h11v05.105.2015034131802.hdf.

Because the source is an HDF4 file, I initially use gdal_translate to built a VRT.

gdal_translate -of vrt -ot UInt16 HDF4_EOS:EOS_GRID:"/path/to/file/MOD16A3.A2014365.h11v05.105.2015034131802.hdf":MOD_Grid_MOD16A3:PET_1km ~/Downloads/temp.vrt

Then, I use gdal_merge.py (because I really want to merge multiple VRTs to build a global mosaic) to output a GeoTIFF.

gdal_merge.py -of "GTiff" -o ~/Downloads/temp.tiff ~/Downloads/temp.vrt

Finally, I use gdalwarp to resample/ reproject the image. The target projection here is a global EASE-Grid 2.0. Note I have multiple srcnodata values that I want to map to a single NoData value in the output.

gdalwarp -t_srs "EPSG:6933" -r bilinear -tr 1000 1000 \
-te -17367530.450 -7301459.170 17336469.550 7314540.830 \ 
-srcnodata "65535 65534 65533 65532 65531 65530 65529" \
-dstnodata 65535 -multi -wo NUM_THREADS=6 -ot UInt16 \
~/Downloads/temp.tiff ~/Downloads/temp_warped.tiff

Unfortunately, the warped file has resampled the srcnodata values. It has set the correct output NoData value (65535) but there are still unmasked values from the srcnodata array and they have contaminated adjacent, resampled pixels. These values are much higher than the expected range, so they're pretty obviously affected by these unmasked srcnodata values.

Reading the array in with GDAL/NumPy, I can verify that I'm asking gdalwarp to mask the right values; the three highest are among my srcnodata values and nothing else comes close:

>>> np.unique(arr)[6300:]
array([18227, 18228, 18230, 18250, 18258, 18259, 18268, 18271, 18275,
       18278, 18281, 18282, 18288, 18292, 18299, 18302, 18304, 18306,
       18315, 18319, 18320, 18322, 18326, 18338, 18341, 18352, 18355,
       18365, 18373, 18385, 18389, 18435, 18465, 18479, 18504, 18535,
       18552, 18555, 18556, 18559, 18561, 18566, 18572, 18594, 18614,
       18622, 18637, 18640, 18735, 18738, 18845, 18867, 18868, 18906,
       19100, 65530, 65533, 65534], dtype=uint16)

Is there something special about specifying multiple srcnodata values? I don't often use more than one. I guess until I figure this out I'll use nearest-neighbor interpolation and manually re-map these values.

Improve this question
2
  • 2
    Does the original file have 7 bands? You cannot assign the nodata tag to more than one value per band, if it is a single band file, you should do a little algebra first, to bring all those values to one, in my opinion.
    – Gabriel De Luca
    Oct 24, 2019 at 23:00
  • It's a single band image--it was not apparent to me that the multiple values correspond, respectively, to each band. I had hoped I could map multiple values for a single band to a single NoData value.
    – Arthur
    Oct 27, 2019 at 17:01

1 Answer 1

Reset to default
2

It was not clear to me at the time that each srcnodata value corresponds to a single NoData value in a given band, i.e., -srcnodata "1 2 3..." indicates that 1 is the NoData value in band 1, 2 for band 2, and so on. As one commenter suggested, a solution would be to use gdal_calc.py or a similar map algebra procedure to collapse multiple desired NoData values to a single value, prior to using gdalwarp.

Improve this answer

Your Answer

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

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