Bug in checking longitude bounds?

[bradlipovsky]

I think there is a bug in checking the longitude bounds for the input of Query (?)

import icepyx as ipx
short_name = 'ATL06'

# spatial_extent = [1, -71, -1, -70] # 1. This works
spatial_extent = [-1, -71, 1, -70]    # 2. This throws an error from line 103 in validate_inputs.py

date_range = ['2018-10-14','2020-06-01']
ipx.Query(short_name, spatial_extent, date_range)

The documentation states "bounding box: Given in decimal degrees for the lower left longitude, lower left latitude, upper right longitude, and upper right latitude"

Technically both spatial_extents above fit this description. The first one just describes a funny bounding box that stretches all the way around the world except for 2deg near the prime meridian.

B

[JessicaS11]

@bradlipovsky Good catch! It looks like when I updated the checks to do a better job handling crossing the dateline, I still missed a bunch of edge cases (one of which you've just found). I'm wondering if there are any tools built into a geospatial library (e.g. pyproj or shapely) that we can use to test for valid inputs rather than enumerating all cases, merely warning the user if they're using the more-likely-fringe first case you present covering nearly the entire world.

Is this a problem you'd like to work on implementing a solution for, or should we open it up to the community for help tackling it?

[liuzheng-arctic]

I bumped into this issue too. I chose a box of [-180, 60, 180, 90] to cover the Arctic region north of 60N. I think anyone who wants to use icepyx to download the full dataset will have the same issue as well. I am not sure the longitude values should be limited when the lower left and upper right corners have different signs. For example, [-179,60,179,62] and [179,60,-179,62]. The first is a long zonal belt and the second is a small 2x2 patch crossing the dateline. If the NSIDC API can handle both as intended, maybe we should just remind the user to double check what they are doing (or even make a plot of the box on a equirectangular map).

[adfraser]

I found it today too: spatial_extent = [0, -80, 90, -60] didn't work, but... spatial_extent = [1, -80, 90, -60] worked fine.

[JessicaS11]

Thanks for reporting your error case, @adfraser.

From a quick look at the CMR API docs, the NSIDC API can handle both sets of coordinates:

[-179,60,179,62] and [179,60,-179,62])

I like @liuzheng-arctic's idea to provide the user with a warning/alert if they are crossing the dateline, perhaps with a "proceed anyway" response required if they're searching for the whole globe. Then our validation checks could be simplified to checking for valid ranges for lat/lon values.

@adfraser @liuzheng-arctic @bradlipovsky are any of you able/willing to work on a solution for this (which might also address #117)? I will not have space on my plate to tackle this in the next few weeks, and it would be an awesome addition to have out in time for the March Hackweek!