You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the last PR we implemented a skyview tool that can be ran with ancillary DEM to output skyview factor map. This output skyview map can be optionally input into ApplyOE. Applying skyview tool on the DEM from the LOC file would result in errors along the borders though (on the order of ~1 km inward into the image), which is why we didn't include the tool directly.
If skyview is not passed (and an array of 1s is created) we can compute an estimate of sky view just as a function of the slope (see page 41 in EnMap processing). One possible approximation is simply $cos^2(Slope/2)$. This of course assumes slope is an actual value and is computed correctly ⚠️ ... Which could cause some very large errors if data are incorrect.
There may be other ways to leverage the horizon tool for some of the interior data, and fallback to this simple method?... It is computationally fast but not negligible, and so there would be no need to run a full horizon computation on a scene that could be assumed to be mostly flat, or could otherwise be approx. well with , $cos^2(Slope/2)$.
Alternatively, instead of having this in geometry which is a bit chaotic… The method could live within skyview.py, and could be called at the start of ApplyOE, and save a sky view image file.. would be easier to implement checks in this way too.
Introduces argument "method" to skyview call - either horizon (A) or slope (B). Slope based method is of course very fast, and for most scenes can be sufficient; however, it will have a positive bias for areas with high relief.. This is because flat slopes can still be obscured and this is not captured in slope method (Fig below)... But notably this will likely always be better than assuming svf=1, since the "slope" method will always be somewhere between the horizon method and 1.0 ... i.e., I'm not sure a negative bias (red) is possible.
Raises exception in ApplyOE if ancillary skyview input ranges from 0-100 instead of 0-1 (ran into this yesterday with APEX data .. ).
Some general cleaning up: deleting svf array to save memory in analytical line, improving comments in skyview.py, bringing in Evan's default of svf=1 (instead of None) in geometry.py, updating geom.check_coszen_and_cos_i() to make it more general (geom.verify()) for usage with skyview and perhaps other future data here.
ApplyOE flag defaults to skyview_factor=None (i.e., svf=1). However, i've modified it so you can easily pass skyview_factor="slope"' . and it should use the OBS slope data for any ISOFIT-ready ENVI file.
This file contains hidden or 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
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.
In the last PR we implemented a skyview tool that can be ran with ancillary DEM to output skyview factor map. This output skyview map can be optionally input into ApplyOE. Applying skyview tool on the DEM from the LOC file would result in errors along the borders though (on the order of ~1 km inward into the image), which is why we didn't include the tool directly.
If skyview is not passed (and an array of 1s is created) we can compute an estimate of sky view just as a function of the slope (see page 41 in EnMap processing). One possible approximation is simply$cos^2(Slope/2)$ . This of course assumes slope is an actual value and is computed correctly ⚠️ ... Which could cause some very large errors if data are incorrect.
There may be other ways to leverage the horizon tool for some of the interior data, and fallback to this simple method?... It is computationally fast but not negligible, and so there would be no need to run a full horizon computation on a scene that could be assumed to be mostly flat, or could otherwise be approx. well with ,$cos^2(Slope/2)$ .