Querying granules by names only?

[whyjz]

Hi Icepyx devs! Does icepyx.Query work if only the granule name is provided? I tried this

filename = 'ATL03_20190805232841_05940403_002_01.h5'
query = icepyx.Query(dataset='ATL03', files=filename)

and it complained that I didn't enter a valid spatial extent. But I didn't know the spatial extent (unless I check it up on Earthdata Search) because I was following somebody else's work with the only file name specified.

Thanks in advance!

[JessicaS11]

Hello @whyjz! If you take a look at the code, the files parameter in the initialization of the query object is actually a legacy placeholder in work towards reading in local files that's not implemented (hence why it's not included in the docstring or examples) that should probably be removed (would you like to submit a PR to do this?). Since filenames are easy to change, it's not a reliable way to search for data from NSIDC anyway. Since you seem to have an unaltered filename in this case, I'd recommend using it to get the track and cycle and input those parameters along with a whole world spatial extent. We did not remove the spatial extent requirement so that users searching for a larger number of tracks/cycles (versus a specific one) did not inadvertently end up with global data if they were only interested in a small region. I haven't tested this to check that you get exactly this granule, but I imagine your code would look something like:

query = ipx.Query(dataset="ATL03", 
                  spatial_extent=[-180, -90, 180, 90], 
                  date_range=['2019-08-05', '2019-08-05'], 
                  cycles=['04'], 
                  tracks=['0594']
                  )

If this still returns more granules than you expect, you could further narrow your search if you know what region of the world you're in (so could reduce the spatial extent) or provide start and end times (which can also be extracted from the filename in this case). Please let us know if this works for you!

[JessicaS11]

@whyjz Can you confirm that you were able to find specific files as suggested?

[whyjz]

Hi @JessicaS11, sorry about the delay from my side (was in quarantine in Taiwan during the past 2 weeks). I actually ended up querying the desired file using a similar way that you posted (see #27 and here). And it is understandable why querying using names only is not recommended. Yes, I am happy to do a quick PR to remove the old placeholder on the doc!

I also found a strange error when I tried your code: if the spatial_extent is set to [-180, -90, 180, 90], it will actually throw an AssertionError: Invalid bounding box longitudes and stop running. Is there something wrong with this assertion or this bounding box format?

[JessicaS11]

No worries, @whyjz! I just happened to have some time to follow up then. Glad you're out of quarantine!

We've had a few issues in the past (e.g. #111, #117) with global coordinates or those crossing the dateline. The format of the bounding box and the assertion itself should be okay, but I don't know that anyone has done extensive testing on it... I wasn't looking at the code and hadn't tried running the code snippet I suggested above (nor this one), but it might be as simple as switching the +/- of the longitudes (spatial_extent = [180, -90, -180, 90]. The valid inputs have to do with what NSIDC accepts as inputs, which I don't know offhand, so even if this makes it through icepyx validation it could run into issues down the pipeline, in which case we'll have to revisit that assertion!

[whyjz]

Switching the sign of the longitudes seems to do the trick. As #117 is probably a better place to track this issue, I will close this issue for now. Thanks for the help these days!