Skip to content
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

1.3.0 SR changes in 039/037 #9

Closed
GoogleCodeExporter opened this issue Apr 20, 2015 · 2 comments
Closed

1.3.0 SR changes in 039/037 #9

GoogleCodeExporter opened this issue Apr 20, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

LE70390372008210EDC00 has a ton of nonveg bright areas next to water, not 
LEDAPS' favorite place, but the diffs b/n SR values before and after ESPA212 
and 213 are concerning. Gail has my before and after files.


Original issue reported on code.google.com by kallie...@gmail.com on 28 Jul 2013 at 5:28

@GoogleCodeExporter
Copy link
Author

Original comment by schmidtg...@gmail.com on 29 Jul 2013 at 4:55

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

The issue flagged regarding the difference in SR values for path 39, row 37 in 
the L7 ETM+ product is due to the difference in ozone data and correctly 
reading it.  I looked at the ozone values that were previously (incorrectly) 
read for the OMI ozone data and the new values, for the center of the scene 
(which is close to the area being flagged).

Ozone at scene center for new code on the Dev system is interpolated between:
298  299
298  297

Ozone for scene center for old code in previous releases is interpolated 
between:
297  293
295  290

So, there are definitely some differences in the ozone values for that scene, 
mainly due to the fact that we corrected the use of the resolution in pulling 
the ozone from the appropriate location.

Furthermore, I reprocessed this scene with the new code and used the old 
resolution and scaling (which would match the previous version of LEDAPS in 
incorrectly reading the ozone data).  The resulting image produced exact 
results across all bands except for 11 pixels total, each with a difference of 
1 (attributed to differences in architectures).

Therefore, I believe this issue is due to the difference in the ozone values 
which are now being read correctly.  I will mark this as invalid/closed.

Original comment by schmidtg...@gmail.com on 29 Jul 2013 at 8:32

  • Changed state: Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant