Following the information on a change in the direct data access URLs, we would like to know when this change will be effective. For the time being, the two following URLs are still valid to download VIIRS/SNPP L1 data :
URL://oceandata.sci.gsfc.nasa.gov/directaccess/VIIRS-SNPP/L1/2022/139/ (old one)
https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-1A/SNPP-VIIRS/2022/139/ (new one)
Correct, both URLs are still active, although the older one is deprecated. We will likely discontinue support for the older path on June 1st (but haven't set that in stone yet). Just know it WILL go away and relatively soon.
I started to modify my scripts to be ready on June 1st
I noticed one problem :
wget https://oceandata.sci.gsfc.nasa.gov (/directdataaccess/Ancillary/GLOBAL/2022/) returns an html file with the list of directories for the days of year 2022, but the names of these directories are href='/directdataaccess/./Ancillary/GLOBAL/2022/047/' instead of href='/directdataaccess/Ancillary/GLOBAL/2022/047/'
with the older URLs, wget https://oceandata.sci.gsfc.nasa.gov (/directaccess/Ancillary/Meteorological/2022/) returns correct subdirectory names (i.e., without the ./).
Are you going to modify it, or do I have to manage it ?
It doesn't' need modifying (or dealing with on your end). The paths are resolvable (otherwise the html links wouldn't work). Sure that extra "./" seems odd (and is superfluous), but the link works the same as if it wasn't there.
The directdataaccess URL is primarily intended for human traversal. While you can write a scrapper script to traverses the pages non-interactively, it would probably be more efficient to use the file_search API for that. We are working to improve the file_search endpoint, so if you've chosen to scrap the HTML pages because of a lack of functionality with the file_search approach, let us know what you use case is and we can see what can be done to meet your needs better.