yori issueshttps://gitlab.ssec.wisc.edu/pveglio/yori/-/issues2023-07-26T14:52:02Zhttps://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/33Incorrect number of bins for Median Distribution2023-07-26T14:52:02ZPaolo VeglioIncorrect number of bins for Median DistributionThe Mediam Distribution is computing the bins using the `range()` function. When the user defines the `stop`, the last bin edge is actually `stop - interval` because of how the `range()` function works. This needs to be corrected.
This ...The Mediam Distribution is computing the bins using the `range()` function. When the user defines the `stop`, the last bin edge is actually `stop - interval` because of how the `range()` function works. This needs to be corrected.
This shouldn't affect the computation of the median.https://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/32Name of attribute Median_Bins to be changed for consistency2023-07-26T14:47:48ZPaolo VeglioName of attribute Median_Bins to be changed for consistency`Median_Bins` attribute in the Median_Distribution variable should be changed to `Median_Bin_Boundaries` for consistency with the attribute `Histogram_Bin_Boundaries` in the histograms`Median_Bins` attribute in the Median_Distribution variable should be changed to `Median_Bin_Boundaries` for consistency with the attribute `Histogram_Bin_Boundaries` in the histogramshttps://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/30Production of aggregated files with user-defined sub-domains2023-07-13T19:05:39ZPaolo VeglioProduction of aggregated files with user-defined sub-domainsFrom a conversation with Rajeev Jain (jain@anl.gov) at SciPy 2023.
Consider implementing an option to allow users to define sub-domains. For example if I'm only interested in a small region I could define a boundary box and my gridded/a...From a conversation with Rajeev Jain (jain@anl.gov) at SciPy 2023.
Consider implementing an option to allow users to define sub-domains. For example if I'm only interested in a small region I could define a boundary box and my gridded/aggregated L3 files would be only confined to that boundary box instead of spanning the whole -90/+90;-180/+180 map.https://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/29min number of pixels with overlapping granules2023-05-03T20:28:07ZPaolo Vegliomin number of pixels with overlapping granulesMinimum number of pixels is applied for each granule. This causes an issue in some cases when multiple granules contribute to the same grid cell, see example below.
I set my `min_pixel_count=6` and I have two granules `A` and `B` tha...Minimum number of pixels is applied for each granule. This causes an issue in some cases when multiple granules contribute to the same grid cell, see example below.
I set my `min_pixel_count=6` and I have two granules `A` and `B` that contribute to the same grid cell.
`A` has 5 valid pixels; `B` has 4 valid pixels.
The aggregated granule should have that cell populated with a `Pixel_Count=9` but Yori discards each of the granules because they are below the threshold.
Solution:
need to move the evaluation of the `pixel_counts` for the purpose of filtering out grid cells at the end of the aggregation stage.Paolo VeglioPaolo Vegliohttps://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/20daily aggregation vs C6?2019-03-27T18:32:45ZSteve Dutcherdaily aggregation vs C6?I believe this is the current logic we use for daily aggregation in Yori:
```
180W to 90W: use 3z on target day to 3z on next day
90W to 0W: use 21z on previous day to 21z on target day
0E to 90E: use 3z on target day to 3z on...I believe this is the current logic we use for daily aggregation in Yori:
```
180W to 90W: use 3z on target day to 3z on next day
90W to 0W: use 21z on previous day to 21z on target day
0E to 90E: use 3z on target day to 3z on next day
90E to 180E: use 21z on previous day to 21z on target day
```
on the PLAT-33 Jira ticket, Paul Hubanks was saying this is the logic they use for C6.
```
For Aqua
Longitude Zone [-180 to -90]
Aqua Late Day Only: 24 hours starting at 03:00 GMT
Longitude Zone [-90 to -0]
Aqua Standard Day: 24 hours starting at 00:00 GMT
Longitude Zone [0 to 90]
Aqua Late Day Only: 24 hours starting at 03:00 GMT
Longitude Zone [90 to 180]
Aqua Standard Day: 24 hours starting at 00:00 GMT
For Terra
Longitude Zone [-180 to -90]
Terra Standard Day: 24 hours starting at 00:00 GMT
Longitude Zone [-90 to -0]
Terra Early Day Only: 24 hours ending at 21:00 GMT
Longitude Zone [0 to 90]
Terra Standard Day: 24 hours starting at 00:00 GMT
Longitude Zone [90 to 180]
Terra Early Day Only: 24 hours ending at 21:00 GMT
```
So Aqua they use the same zones as we do for 1 & 3 and for Terra they use the same zones we do for 2 & 4. The question we have is does our aggregation produce a similar result? In other words does using all 4 zones for both satellites cause differences in the product. I know there will be differences on granules near the poles but for granules near the equator I suspect not.
What I would suggest that you do is make a test branch of yori with 2 new command lines arguments, something like aqua_daily and terra_daily where it uses the logic above. Then create a L3 product for both Aqua and Terra using both our daily aggregation and then the corresponding new aqua_daily and terra_daily. You should be able to validate the result by gridding up observation time and then comparing the two datasets.
Paolo,
Do you have the free cycles to look into this?https://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/14Multiple overpasses2017-11-07T19:39:59ZPaolo VeglioMultiple overpassesBryan asked if there's a way of dealing with multiple overpasses.
Specifically, how to solve the problem of having data from multiple orbits in the same grid cell.
The goal would be to have a grid cell filled with only one overpass per...Bryan asked if there's a way of dealing with multiple overpasses.
Specifically, how to solve the problem of having data from multiple orbits in the same grid cell.
The goal would be to have a grid cell filled with only one overpass per day, so that it isn't filled with data hours apart where the conditions might have changed.
edit:
just noticed that this is the same issue #5 that Steve opened a while ago. I'll leave it here for now, so that we know that there's more than one person asking for this featurehttps://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/13Thresholding on aggregation based on number of valid pixels per grid cell2017-11-02T14:45:11ZPaolo VeglioThresholding on aggregation based on number of valid pixels per grid cellAnother request from Andy Sayer:
> is there any ability to implement thresholding? If not, is this something which is easy to add?
> For example, in the MODIS level 3 aerosol products, at least 3 (I think) retrievals are needed for a...Another request from Andy Sayer:
> is there any ability to implement thresholding? If not, is this something which is easy to add?
> For example, in the MODIS level 3 aerosol products, at least 3 (I think) retrievals are needed for a daily 1 degree grid cell to be considered valid, and at least 3 days are needed for a monthly grid cell to be considered valid.https://gitlab.ssec.wisc.edu/pveglio/yori/-/issues/7Inverse Masks2017-12-08T15:17:56ZPaolo VeglioInverse MasksDo we want to support the use of inverse masks?
Pros:
- save some space for the input files
- Yori can handle them with some minor tweaks
Cons:
- limited use
- unnecessary "complication" of the codeDo we want to support the use of inverse masks?
Pros:
- save some space for the input files
- Yori can handle them with some minor tweaks
Cons:
- limited use
- unnecessary "complication" of the code