Hello,
Could you clarify the temporal semantics of this MOD13Q1 Collection 6.1 granule?
Product: MOD13Q1.061
Granule: MOD13Q1.A2012353.h25v04.061.2021224010348.hdf
RangeBeginningDate: 2012-12-18
RangeEndingDate: 2013-01-02
In a 96x96 native-grid window, the official HDF contains Pixel DOY values 3, 5, 7, and 8 in 6,749 pixels with non-fill NDVI. Under year-end rollover, these correspond to dates from 2013-01-03 through 2013-01-08. The HDF's INPUTPOINTER includes A2013001 MOD09 inputs.
The corresponding AppEEARS output matches the official HDF exactly for Pixel DOY, NDVI, DetailedQA, and Pixel Reliability: 36,864 integer values compared, with zero mismatches. Native-grid coordinates and indexing also agree.
PCR17-021 mentions end-of-year processing and "days from next cycle":
https://modaps.modaps.eosdis.nasa.gov/cgi-bin/PCR_detail.cgi?file=/Land/PCR17-021.dat
Could you please clarify:
1. Are next-calendar-year pixel acquisition DOY values expected and valid in the final 16-day MOD13Q1 composite of a year, including this specific case?
2. Does RangeEndingDate strictly bound all source observations contributing to selected pixels, or does it describe only the nominal granule/composite temporal extent?
3. For scientific lineage and train/validation/test split-boundary handling, should pixel-level DOY be treated as the actual observation date when it extends beyond RangeEndingDate? If so, how should the calendar year be assigned?
A reference to the applicable product documentation or processing specification would be appreciated.
Thank you.
MOD13Q1.061 year-end Pixel DOY versus RangeEndingDate
-
robbot_abchihgtsv1j
- Posts: 1
- Joined: Sat Oct 10, 2026 12:08 pm America/New_York
-
LP DAAC - lien
- User Services
- Posts: 92
- Joined: Mon Mar 17, 2025 2:04 pm America/New_York
- Endorsed: 6 times
Re: MOD13Q1.061 year-end Pixel DOY versus RangeEndingDate
Hello,
We contacted the MODIS Vegetation Science team on these, and here are their comments and recommendations:
Thanks for running this by our group, and here are some clarifications:
1. Are next-calendar-year pixel acquisition DOY values expected and valid in the final 16-day MOD13Q1 composite of a year, including this specific case?
· Yes, this behavior is expected. Over time, the VI algorithm has undergone several changes, some of which were not thoroughly documented or tracked. This is one such case.
Since the beginning of the VI product suite, the algorithm has allowed observations from the following calendar year to be used when necessary to complete the final 16-day compositing period. This approach was originally implemented when the VI products were generated using daily surface reflectance observations.
Beginning with Collection 6 (C6), the VI product suite transitioned to using precomposited surface reflectance data from MOD09 8-day composites, which are generated using the minimum-blue compositing method.
Unlike daily inputs, which provided greater flexibility in selecting the best available observation (or the least affected by atmospheric and other conditions), each MOD09 composite represents an entire 8-day period. Consequently, the algorithm must either accept or reject the 8-day composite as a whole, rather than select individual daily observations.
This change presented a trade-off at the end of the calendar year. We could either exclude data from the following year and complete the final VI composite using only the last available MOD09 composite of the current year, or include the first MOD09 8-day composite of the following year when it overlaps with the remaining days needed to complete the 16-day period.
We chose the latter approach to maximize data completeness and avoid losing potentially valuable observations. However, this means that the selected MOD09 input may contain a pixel acquisition DOY that falls outside the nominal 16-day compositing window, including dates in the following calendar year. Like what you are seeing here.
This was a deliberate and consistent with our objective of producing high-fidelity vegetation index data while minimizing gaps and preserving as many valid observations as possible.
2. Does RangeEndingDate strictly bound all source observations contributing to selected pixels, or does it describe only the nominal granule/composite temporal extent?
· See above.
· The algorithm is designed to restrict input observations to the 16-day compositing period. However, transitioning from 16 daily observations, which provided greater flexibility in selecting the best available observation/DOY, to only two or three precomposited MOD09 8-day observations significantly reduced our selection options. As a result, we had to make a compromise and allow the use of MOD09 observations even when their acquisition dates fall outside the nominal 16-day compositing window, as illustrated in this case.
3. For scientific lineage and train/validation/test split-boundary handling, should pixel-level DOY be treated as the actual observation date when it extends beyond RangeEndingDate? If so, how should the calendar year be assigned?
· Good question. The most accurate approach is to assign each pixel to its actual acquisition day of year (DOY) and corresponding calendar year. However, for regional, long-term, or large-scale analyses, where you have to average multiple pixels for an area, etc., and depending on the specific application, you cannot do that since pixels come from different DOY. In such cases, assigning the observation to the DOY indicated in the granule name (the start of the compositing period) is a reasonable approach.
Since composited data are designed to represent conditions over a 16-day period using a single selected observation, assigning the midpoint (date) of the compositing period is also a valid option for large-scale analyses.
However, for individual pixel-level analyses, particularly when precise temporal information is important, I would recommend using the actual acquisition DOY and calendar year to maintain the highest possible temporal accuracy.
Hope that helps
Thanks,
LPDAAC
We contacted the MODIS Vegetation Science team on these, and here are their comments and recommendations:
Thanks for running this by our group, and here are some clarifications:
1. Are next-calendar-year pixel acquisition DOY values expected and valid in the final 16-day MOD13Q1 composite of a year, including this specific case?
· Yes, this behavior is expected. Over time, the VI algorithm has undergone several changes, some of which were not thoroughly documented or tracked. This is one such case.
Since the beginning of the VI product suite, the algorithm has allowed observations from the following calendar year to be used when necessary to complete the final 16-day compositing period. This approach was originally implemented when the VI products were generated using daily surface reflectance observations.
Beginning with Collection 6 (C6), the VI product suite transitioned to using precomposited surface reflectance data from MOD09 8-day composites, which are generated using the minimum-blue compositing method.
Unlike daily inputs, which provided greater flexibility in selecting the best available observation (or the least affected by atmospheric and other conditions), each MOD09 composite represents an entire 8-day period. Consequently, the algorithm must either accept or reject the 8-day composite as a whole, rather than select individual daily observations.
This change presented a trade-off at the end of the calendar year. We could either exclude data from the following year and complete the final VI composite using only the last available MOD09 composite of the current year, or include the first MOD09 8-day composite of the following year when it overlaps with the remaining days needed to complete the 16-day period.
We chose the latter approach to maximize data completeness and avoid losing potentially valuable observations. However, this means that the selected MOD09 input may contain a pixel acquisition DOY that falls outside the nominal 16-day compositing window, including dates in the following calendar year. Like what you are seeing here.
This was a deliberate and consistent with our objective of producing high-fidelity vegetation index data while minimizing gaps and preserving as many valid observations as possible.
2. Does RangeEndingDate strictly bound all source observations contributing to selected pixels, or does it describe only the nominal granule/composite temporal extent?
· See above.
· The algorithm is designed to restrict input observations to the 16-day compositing period. However, transitioning from 16 daily observations, which provided greater flexibility in selecting the best available observation/DOY, to only two or three precomposited MOD09 8-day observations significantly reduced our selection options. As a result, we had to make a compromise and allow the use of MOD09 observations even when their acquisition dates fall outside the nominal 16-day compositing window, as illustrated in this case.
3. For scientific lineage and train/validation/test split-boundary handling, should pixel-level DOY be treated as the actual observation date when it extends beyond RangeEndingDate? If so, how should the calendar year be assigned?
· Good question. The most accurate approach is to assign each pixel to its actual acquisition day of year (DOY) and corresponding calendar year. However, for regional, long-term, or large-scale analyses, where you have to average multiple pixels for an area, etc., and depending on the specific application, you cannot do that since pixels come from different DOY. In such cases, assigning the observation to the DOY indicated in the granule name (the start of the compositing period) is a reasonable approach.
Since composited data are designed to represent conditions over a 16-day period using a single selected observation, assigning the midpoint (date) of the compositing period is also a valid option for large-scale analyses.
However, for individual pixel-level analyses, particularly when precise temporal information is important, I would recommend using the actual acquisition DOY and calendar year to maintain the highest possible temporal accuracy.
Hope that helps
Thanks,
LPDAAC