Closed BENR0 closed 8 months ago
Attention: 2 lines
in your changes are missing coverage. Please review.
Comparison is base (
e82bf47
) 94.06% compared to head (e560f1c
) 94.05%.
Files | Patch % | Lines |
---|---|---|
pyresample/geometry.py | 75.00% | 2 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Glad that you like it was not sure if it is a valuable addition. I just used it because I was to lazy to create Affine transformations from scratch and was thinking that maybe I can test some stuff for rerprojections and maybe for the html representation.
Cool feature @BENR0. I never used the odc-geo tool. But from a quick look @djhoese:
area_def = satpy.resample.get_area_def("goes_west_abi_f_1km"
)get_bbox_lonlats
of AreaDefinition. But it's worth?BTW I just opened the PR https://github.com/pytroll/pyresample/pull/546 to streamline the boundary extraction
does not support swath definition data
Sure, but I think that's the point. They're projected bounding boxes.
I am not sure it currently support areas crossing the antimeridian (@BENR0 could you test the result with GOES-17 AreaDef? area_def = satpy.resample.get_area_def("goes_west_abi_f_1km") The implemented geometry operations are implemented wrapping shapely ... so classical problems ... --> We could maybe use the odc-geo for the get_bbox_lonlats of AreaDefinition. But it's worth?
I would suspect they don't currently support the anti-meridian as that is technically not a valid contiguous space on any CRS. If you have data that crosses the anti-meridian of a CRS then your data can't be represented correctly on that CRS. This is strict and difficult to reconcile in real world applications with data crossing the poles, but it is technically true. I know you have workarounds in your other PRs since we do end up having to deal with it, but I just wanted to point this out.
As for using odc-geo in other methods of the geometry objects: no thank you. Not yet. Not unless it is a clear win for doing calculations. No need for the extra dependency.
Not that I expected this to happen in this PR, but we really need to come up with a new pattern for conversion of areas to other things. I'm not sure dumping it all in geometry.py is a good idea.
Convert
AreaDefinitions
to odc geoboxes (https://odc-geo.readthedocs.io/en/latest/).git diff origin/main **/*py | flake8 --diff