Allow cropping non-geos areas

[mraspaud]

• [x] Tests added
• [x] Tests passed
• [x] Passes git diff origin/main **/*py | flake8 --diff
• [ ] Fully documented

[mraspaud]

@ameraner you might want to have a look at this also

[codecov[bot]]

Codecov Report

Merging #516 (44af636) into main (2a6d769) will decrease coverage by 0.10%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #516      +/-   ##
==========================================
- Coverage   94.34%   94.25%   -0.10%     
==========================================
  Files          82       82              
  Lines       13026    13030       +4     
==========================================
- Hits        12290    12282       -8     
- Misses        736      748      +12     

Flag	Coverage Δ
unittests	94.25% <100.00%> (-0.10%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
pyresample/geometry.py	87.64% <100.00%> (+0.05%)	:arrow_up:
pyresample/test/test_geometry/test_area.py	99.21% <100.00%> (+<0.01%)	:arrow_up:

... and 1 file with indirect coverage changes

[djhoese]

If I'm not mistaken this will mean that reduce_data in Satpy will now cause a performance hit for all LEO data right? For some reason I thought reduce_data depended on this failing to not have reduce_data be performed on LEO/SwathDefinition data.

[djhoese]

Yep, this NotImplementedError handling here:

https://github.com/pytroll/satpy/blob/4f6a7c35ce8a620428f51ff086e3276a73c72c97/satpy/scene.py#L903-L926

[mraspaud]

If I'm not mistaken this will mean that reduce_data in Satpy will now cause a performance hit for all LEO data right? For some reason I thought reduce_data depended on this failing to not have reduce_data be performed on LEO/SwathDefinition data.

So maybe we should check that the it is an areadef not swathdef here? or should that be done in satpy to keeps things cleaner here?

[djhoese]

Oh I'm wrong. There is an AreaDefinition check at the top of the method. This is probably good then.

[ghiggi]

@mraspaud: FYI there are several edge cases where this method currently fails:

• When a swath/area intersects twice with another area, the polygon intersection routine currently runs infinitely if the intersections are more than 1
• When an area is within (or touches) another, I think that the intersection now runs infinitely ...

If you implement get_array_indices_from_lonlat method also for SwathDefinition, then the method would work also when area_to_cover is SwathDefinition ;)

[mraspaud]

Oh I'm wrong. There is an AreaDefinition check at the top of the method. This is probably good then.

I can't see it, could you point me to it please?

[djhoese]

Here:

https://github.com/pytroll/pyresample/blob/3fa952985b8b4a62f4407e1cdeef166719523e47/pyresample/geometry.py#L2570-L2571

[djhoese]

Hhhmmm maybe I should have merged this before my big config PR. Sorry, but I've caused some conflicts.

[mraspaud]

Fixed.

[coveralls]

coverage: 93.864% (-0.09%) from 93.953% when pulling 44af63609906f04ffea1e7fc0d4aad4fd826a3ab on mraspaud:feature-non-geos-crop into 2a6d7694265a13f78b2f76b4951f6851dceb30c8 on pytroll:main.

[mraspaud]

@djhoese please review my two last commits to see if you agree with the refactoring I made.

This refactoring took me some time because I found a bug/inconsistency in the usage of the frequency argument in AreaDefBoundary and the boundary method of area defintion: in the first case it means the step we use to determine the length of the boundary, in the second case it is the length of the boundary itself. I'm working on a fix now (which will be another PR).

[ghiggi]

I remember I noticed such inconsistencies already a while ago. For GEO areas is the total number of vertices, while for swath and other areas is the number of steps on each boundary side right? I personally would really like to have this as the number of vertices per boundary side, and allow to specify a tuple (y,x) or (x,y) instead of a single value for all dimensions.

I also remember somewhat that quite ago, by using the step approach, we were discarding boundary corners values, but I think this was fixed by one of mine or your PR @mraspaud.

[mraspaud]

@ghiggi I think both approaches are valid, the usage just depends on what the user needs at that point.

in https://github.com/pytroll/pyresample/pull/526 I have now just replaced frequency with bbox_shape as a more accurate name. I don't change any functionality or behaviour though, so allowing to pass a tuple for example isn't supported (yet?)

[mraspaud]

which then reaches a PendingDeprecationWarning

Indeed, this is now fixed.

[djhoese]

@mraspaud I think I understand the last 2 commits. I assume the main motivation was to:

1. Remove use of AreaDefBoundary
2. Use one method for getting the boundaries for both the source and cover(target) areas.

So if that is true then :+1: from me.