-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avhrr_l1b_gaclac fails to read most files from NOAA CLASS #2494
Comments
Thanks for reporting this! |
Thanks for the report! I haven't seen this before, and we are using data from NOAA CLASS quite often. Did you uncheck the "include archive header" (or similar) option in your user preferences? Pygac is currently not able to read files with the CLASS archive header included. |
Sorry, I was wrong. Pygac can handle the archive header. |
I have tried with and without the archive header on another file. I have ordered the 2 files I linked in the issue again both with and without the archive header, and I will try that. |
Looks like the timestamps are corrupt in the failing file, we're looking at it. |
Here are two plots of the raw timestamps before any processing.
I think there's nothing we can do about that, except setting all timestamps to NaT if the year is outside [1970, today] or something like that. |
Oh... |
I'll ask my colleagues if they experienced something like that recently. |
Satpy/Pygac are dependent on valid times, so corrupt timestamps like these will be a problem. |
I tested with data from my colleagues and found no issues on that day. They got the data via CLASS subscription. So maybe something went wrong with your order... |
I think I just figured it out, All the files I was downloading where 16 bits/pixel. I just ordered them again with 10 bits/pixel and now they work. I ordered again with 16 bits/pixel and the same error. That explains the "Unexpected number of scanlines!" error too. I must have accidentally selected 10 bits/pixel for the two working files. I guess avhrr_l1b_gaclac only supports 10 bits/pixel data. |
@thomasdouwes oh, nice find! thanks for reporting back! |
Describe the bug
A clear and concise description of what the bug is.
When using the avhrr_l1b_gaclac reader to load NOAA POES GAC files from NOAA CLASS, most file will fail to load when Scene.load is called.
To Reproduce
Fail:
Try to load NSS.GHRR.NK.D23133.S0714.E0907.B3003031.WI
success:
Try to load NSS.GHRR.NK.D23133.S0902.E1057.B3003132.WI
Expected behavior
A clear and concise description of what you expected to happen.
AVHRR channel one is loaded into the scene
Actual results
Text output of actual results or error messages including full tracebacks if applicable.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment Info:
Additional context
Add any other context about the problem here.
gdal_translate can successfuly read all of the files.
Even the working file produces a lot of warnings, here is the log trying to load the working file:
I have tried 28 different GAC files from CLASS and only two have worked, I'm not sure what about the files that work is different but it seems unlikely to me that the majority of the files I downloaded are corrupted.
I have also tried running the script in a python 3.10 conda enviroment but it still did not work.
The files are full GAC so they are too large to attach to this github issue so I have uploaded then to my website (hopefully that is alright):
working: i3b.co/NSS.GHRR.NK.D23133.S0902.E1057.B3003132.WI
not working: i3b.co/NSS.GHRR.NK.D23133.S0714.E0907.B3003031.WI
The text was updated successfully, but these errors were encountered: