Fix selection of user defined scanlines #2 #15
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the presence of scanlines with invalid lat/lon info, user defined scanlines are not selected correctly. - Fix selection of user defined scanlines - Add tests covering that problem
Set to None if it has been removed due to invalid lat/lon info
Didn't work at the end of a month
Use test timestamps with year and month switch
Since pytroll#11 UTC timestamps are saved to file. They have to be sliced like the other variables in save_gac().
Set to None if midnight scanline is outside the user defined scanline range
Use mock to patch methods
sfinkens
changed the title
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remake of #12
I believe there is a bug in
pygac.gac_io.save_gac. User defined scanlines are not selected correctly in the presence of scanlines with invalid lat/lon info:data = data[temp_start_line:temp_end_line]start_line/end_lineto new slicedata = data[start_line, end_line]I believe step 2 is not done correctly. Here is a sketch with the details: pygac_2step_slice.pdf
The consequence for CLARA-A2 is, that we get scanlines beyond the requested range from pygac. As the range was chosen to avoid overlap between consecutive orbits, we re-introduce an overlap of
temp_start_linescanlines. I did a quick CLARA-A2 logfile analysis:In 2011 almost every orbit from every platform is affected, but luckily the average temp_start_line is 15, which is not a serious problem. In 1984, the additional overlap is quite significant, but only very few orbits are affected.
Cloud_cci is not affected at all, because they always process all scanlines.