Determining fill/invalid values in MOD17A3HGF

[amyjwalker]

Hi, I wanted to ask a question about valid values of NPP and GPP for MOD17A3HGF files. I’ve removed some fill values ie above 30,000 as recommended in the report "User’s Guide, GPP and NPP (MOD17A2/A3) Products
NASA MODIS Land Algorithm" which states that "All pixels without a GPP calculation will have a value greater than 30,000, regardless of the reason for the missing values”
I’ve also removed negative values as recommended. However, looking at the resulting data, there are huge number of cells with 30000 as their value. I would like to find out how to determine if they are all valid values having removed the obvious invalid ones, and how to determine those which are not valid due to cloud cover, striping etc. Is there a way to tell valid values from invalid values, without disregarding potentially extremely high values that may be accurate?
Many thanks for your help! Amy

[LP DAAC - lien]

Hi Amy,
Probably the most accurate way to decide if these higher value pixels are valid are to check with the QC layer. The Psn_QC_500m has this information within its encoded bits. Please see pages 22 and 23 of the User Guide for the bit index. Please let me know if you have any questions.
Thanks,
Brett

[amyjwalker]

Hi Brett, thank you so much for getting back with this info. I’ve been looking into using the Npp_QC_500m layer and using it to check values with the NPP data. I’m looking at doing the same thing for the GPP data as well, but I just wanted to double check which QC layer to use? Is the Psn_QC_500m layer in the MOD17A2HGF the right one for GPP, and the Npp_QC_500m for NPP?
Thanks so much once again, I’m so grateful for your help. Amy

[LP DAAC - lien]

Hi Amy,
Could you send me an example granule ID for a MOD17A3HGF you are working with that is that way, then I would have a specific area and year so I could take a look at the anomaly. The Yearly should not have those issues; it is just the sum of the 8-days for that year. So, we should figure out why so many pixels are at the very top of the valid range.
Thanks,
Brett