New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix nodefilter not working with Sentinel-3 products #573
Conversation
Introduced the 'manifest_name' key in the odata dictionary in order to properly handle the product path and manifest filename depending on the type of product.
The _download_with_node_filter function now uses the 'Filename' and 'manifest_name' dictionary keys to create the product folder and manifest filename depending on the type of product queried by the user. The _dataobj_to_node_info function sets the "node_path" dictionary key using the path variable rather than recalling the "href" key of the dataobj_info object, so that the initial './' characters are removed if they were present in the original object. Not doing so causes the failure of the nodefilter function for Sentinel-3 products. Partial downloads of other products work normally.
Now the product folder path and the manifest filename are set based on the 'title' key of the odata dictionary. This ensures that Sentinel-3 paths and manifest filenames are set correctly, allowing nodefilters to function also with these products. The previously introduced 'Filename' key was removed in favour of the newly introduced 'manifest_name', which is then used to build the paths throughout the code.
Build the product folder path without querying the full metadata through get_product_odata, making use of the new 'folder_path' key of the product_info dictionary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I agree, looks good and is an improvement in terms of avoiding hard-coded names. CI shows you need to Black-format, please, then we'll know how the rest of the tests go. |
I used the black linter included in Spyder and the number of changes in the code is much higher than I expected. From what I can see basically all of them seem to be breaking down lines that are longer than 79 characters. Is this ok? Or did I use the wrong code formatter? |
@valpamp the configuration for black is in the Lines 1 to 16 in 3682e43
The |
I finally managed to run black with using the proper configuration file, it should be ok now. |
Great, now Black is happy, but one test is failing because the product info we expect (from recordings) is different from what we have now, where the Would you try to re-record that cassette, @valpamp? There are some instructions on that here: https://github.com/sentinelsat/sentinelsat/#tests If it does not work for you, we can help. Before you do, I am not super happy with the naming of So should we still consider renaming it to |
|
Great, thanks, @valpamp! Sounds right with |
Removed the initial './' to match the actual content of the product_info set.
Hey everyone, sorry this took so long, I had to turn in my PhD thesis and I have been completely absorbed in that for a while. Today I finally ran pytest in my conda environment, and the test failure seems to be caused by a mismatch between the content of the sentinelsat/tests/test_download.py Line 376 in 7fd4122
The However, if I now run pytest without the |
I can see the test is using the first of these recent Sentinel-1 products: Line 293 in 7fd4122
sentinelsat/tests/test_download.py Line 366 in 7fd4122
Have you tried using a different one, e.g. the second from that query? Or try again tomorrow, when the query hopefully returns some different products. If the problem persists, it might be more systematic. Thanks for your efforts - and good luck with the thesis! |
I ran more tests with the other two products and I am getting different errors. If I run the test with Finally, yesterday I found and solved another weird issue with the node filter on Sentinel-2 products from 2018. But I will open another issue/PR for that. |
I can reproduce the issue with the truncated manifest.safe even on current
The copy of the file |
The recorded fixture |
Btw, why is the sentinelsat/tests/test_download.py Lines 370 to 371 in 8211224
|
@j08lue the manifest contains the full list of files included in the product. It is always downloaded and parsed to extract the file list (and associate metadata), then filters use this information to decide if a file shall be actually downloaded. |
To keep things consistent since the rest of the code uses "directory" instead of "folder".
Codecov Report
@@ Coverage Diff @@
## main #573 +/- ##
==========================================
+ Coverage 84.44% 84.51% +0.07%
==========================================
Files 7 7
Lines 1292 1298 +6
Branches 335 322 -13
==========================================
+ Hits 1091 1097 +6
Misses 145 145
Partials 56 56
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
No longer supported by the GitHub action.
Windows and MacOS started to require a token for some reason. Might be a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for completing this long-standing PR, @valgur.
Fixes issue #566, which was caused by the code not handling the product folder path and manifest filename based on the type of product. Since most Sentinel products have a folder path ending in .SAFE and a manifest file named manifest.safe, this was an issue only with products such as Sentinel-3, whose folder path ends in .SEN3 and whose manifest file is named xfdumanifest.xml.
By fetching the full odata metadata of the queried product, it is possible to get the correct folder path, and sets the manifest filename accordingly.
If there are products whose folder path does not end in '.SAFE' or '.SEN3', they should be handled accordingly.