Skip to content
This repository has been archived by the owner on Jul 19, 2022. It is now read-only.

Fails to re-download data if there was a network error #4

Closed
mantleCurve opened this issue Jul 25, 2020 · 4 comments
Closed

Fails to re-download data if there was a network error #4

mantleCurve opened this issue Jul 25, 2020 · 4 comments

Comments

@mantleCurve
Copy link

mantleCurve commented Jul 25, 2020

If any of the bands (blue, green or red) fails during the download, felicette doesn't re-download it. Rerunning the program again for the specific place shows the required data exists for the said band. But in reality it is an incomplete download. This throws an error

rasterio.errors.RasterioIOError: Read or write failed. /home/mithun/felicette-data/LC81430542020100/LC81430542020100-b4.tiff, band 1: IReadBlock failed at X offset 1, Y offset 6: TIFFReadEncodedTile() failed.

Current workaround is to delete the folder and run again.

@plant99
Copy link
Owner

plant99 commented Jul 25, 2020

I'd prioritize this and add it to To-Do.

Let's see if there are options to validate check-sums of band files, so it doesn't download the required data all over again.
Another way is to handle the removal of the data directory on except rasterio.errors.RasterioIOError in felicette/sat_processor.py

@mantleCurve
Copy link
Author

If checksum can be implemented, that would be the best option

Or can go with '--refresh' flag 🚩

The folder delete on exception should be done on network error and not after the above mentioned exception. If the first band is error, the second and third gets downloaded before the exception, which would be useless.

@plant99
Copy link
Owner

plant99 commented Jul 26, 2020

3447b78 this commit partially fixes this issue, by catching the RasterIOError, deleting the data dirs, and reattempting download and processing.

@plant99 plant99 closed this as completed Jul 26, 2020
@plant99
Copy link
Owner

plant99 commented Jul 26, 2020

A long term solution to this would be using check-sums, but will add this to to-do, due to less bandwidth. Feel free to reopen the issue if the problem persists after the next release

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants