Closed cikelly closed 1 year ago
Thanks for spotting this! This happened from the attempt to get at last one full cycle before a sentinel 1 acquisition. I hadn't been using it with the "date" argument for awhile, but we should just make that into a datetime
(since right now it goes to time 00:00 on the date you specify, which is covered in your example)
Should be a hard fix, so you could try if you'd like, otherwise I'll push up something shortly
your test case now grabs the one which covers the entire date:
$ eof --date '20190312' --mission S1A
[10/14 20:03:47] [INFO download.py] Attempting download from SciHub
Downloading S1A_OPER_AUX_POEORB_OPOD_20210316T133354_V20190311T225942_20190313T005942.EOF: 100%|██████████████████████████████████████████████████████████████████████████████| 4.41M/4.41M [00:05<00:00, 874kB/s]
Downloading products: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1/1 [00:06<00:00, 6.24s/product]
SentinelOrbit('S1A_OPER_AUX_POEORB_OPOD_20210316T133354_V20190311T225942_20190313T005942.EOF')
Out[5]:
SentinelOrbit(
filename='S1A_OPER_AUX_POEORB_OPOD_20210316T133354_V20190311T225942_20190313T005942.EOF',
orbit_type='precise',
start_time=datetime.datetime(2019, 3, 11, 22, 59, 42, tzinfo=datetime.timezone.utc),
stop_time=datetime.datetime(2019, 3, 13, 0, 59, 42, tzinfo=datetime.timezone.utc)
)
Thanks for fixing this!
Hi Scott,
It appears download_eofs() now downloads the wrong orbit file, specifically the orbit file for the day before the date of interest. For instance, download_eofs(['20190311'], ['S1A']) downloads the orbit file for 20190310 (S1A_OPER_AUX_POEORB_OPOD_20210311T132551_V20190309T225942_20190311T005942.EOF).
I don't know Python enough to figure out where the problem is coming from. However, potential workarounds are:
download_eofs(['20190312'], ['S1A']