Open mraspaud opened 1 year ago
@BENR0 ^
Merging #476 (71a019c) into main (1268d90) will increase coverage by
0.01%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## main #476 +/- ##
==========================================
+ Coverage 94.28% 94.29% +0.01%
==========================================
Files 69 70 +1
Lines 12394 12417 +23
==========================================
+ Hits 11686 11709 +23
Misses 708 708
Flag | Coverage Δ | |
---|---|---|
unittests | 94.29% <100.00%> (+0.01%) |
:arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Impacted Files | Coverage Δ | |
---|---|---|
pyresample/geometry.py | 87.22% <100.00%> (+0.05%) |
:arrow_up: |
pyresample/test/test_gcp_def.py | 100.00% <100.00%> (ø) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
I'm not sure I understand all of the use cases for GCPs, but I thought they were a sparse version representing something much larger. How does this work here with your definition? Put another way, I thought the user would give GCPs and like an overall shape of the area and that would be used to generate the full lons/lats on the fly. Where is
get_coarse_bbox_lonlats
going to be used? It isn't used currently, right? How useful is it when we have access to the full lons/lats already? How will the user control whether "coarse" bounding boxes are good enough for their use case?
Yes, very good questions indeed.
I think another use case that was mentioned by @mraspaud was to be able to write geotiffs with only tiepoints.
Add a new class called GCPDefinition (inherits from SwathDefinition) which provides access to the underlying gcps.
Use cases:
faster loading of coarse lon/lats (for the boundary)
if you want to write data with tiepoints
interpolate a fraction of what is needed.
[ ] Closes #xxxx
[x] Tests added
[ ] Tests passed
[ ] Passes
git diff origin/main **/*py | flake8 --diff
[ ] Fully documented