subset_spatial won't select 'long' rectangles

[JanisGailis]

Expected behavior

When trying to view the arctic area, I would like to select a long polygon on 'top' of the map and plot it in polar_stereographic projection.

Actual behavior

When we convert PolygonLike to shapely polygons we loose the information regarding which value was lon_min, which was lon_max, as the smallest absolute value will be regarded as min. E.g., if a user provides {'lon_min':170, 'lon_max':-170}, intending to select 20 degrees, this will be converted to {'lon_min':-170, 'lon_max':170}, selecting 160 degrees.

To work around this, a heuristic is used in subset_spatial, assuming that users typically don't select very large rectangles on the map, and usually the smallest version of two possibilities is the correct one.

When trying to select the polar region, this assumption fails.

Steps to reproduce the problem

Try to use subset_spatial()'' with {'lon_min': -185, 'lon_max': 185}``, observe a small slice crossing the international date line being selected.

Specifications

Latest Cate dev

[JanisGailis]

I see two possible solutions:

1. Create subset_simple operation that doesn't use PolygonLike to not loose information about original coordinate extremes.
2. Add select_larger=False optional parameter that would alter original behavior of existing subset_spatial to make it possible to select large rectangles.

Maybe there is another possibility?

[JanisGailis]

@forman Can you comment what's your take on this?

[forman]

Extend subset_spatial to accept a region: RegionLike argument, where RegionLike would also include the 4-tuple (lon_min, lat_min, lon_max, lat_max).

If it encounters the a 4-tuple region, it will recognise the lon_min and lon_max range without heuristics.

This is actually only a small change as we already accept 4-tuple regions implicitly in PoylgonLike. Maybe we can also simply stay with PoylgonLike and only implement the extra logic in subset_spatial.

[JanisGailis]

Thank you!

I like staying with PolygonLike. I can explicitly validate before converting and if it happens to be a 4-tuple (string or an actual tuple), use that explicitly. I like this. Crazy how I didn't think of this myself.