Why don’t you want to update to 8.0?
It would be useful, if we could get an ETA on when gnss scihub will have the latest sets of orbits streaming in consistently. Right now, gnss site seems to have patchy coverage from Mar 11-14 (with no updates on the aux, which is ok), whereas SLC data seems to be streaming in.
Any heads up will be useful for preparation at our end.
Thanks
Piyush
Why don’t you get in touch with the official Sentinel support. and ask that same question?
This forum is for the SNAP and related Toolboxes not the Sentinel data generation and distribution for which the official support channel above exists.
Off course someone else here may have already contact them and obtained a reply to the question and is able to share…
I apologize. They appear to be overwhelmed and there haven’t been not too many updates/ responses lately. I was hoping, like you said, that others might have insight into the ongoing issue.
No need to apologise, just trying to manage expectations. The way you are posing the question seem to expect a reply from someone who can give you an ETA - this will not come in this forum. The teams in charge of the production and dissemination are not monitoring this place. Some members of the quality control teams do it informally, but that’s the most I have seen here.
The support helpdesk is there to reply to important questions like this, overwhelmed or not. They may have the information that you are looking for and be able to reply quickly.
1 Like
The reason why I would like to be able to use SNAP 7.0 a little longer is that I am processing a longer time series and would like to avoid breaking its continuity, which a software update might do. I did not have a change to test SNAP 8 well enough yet, but will of course get to that as soon as possible.
Also, I had trouble running the module update command when building a Docker image for SNAP 8. Figured it out, though: when fonts are lacking, as is the case in headless Linux images, the module update command fails at some point and then restarts, repeating that indefinitely… Install the fonts and it works, at least with the kill switch workaround. But that is material for a separate issue…
Anyways, if you can back-port the fix to 7, I suspect that there are also other people who did not upgrade yet and would be very happy to be able to get the aux files again.
1 Like
It is a double-edged sword, since we only support the latest official version we would like to keep the number of users using obsolete versions as low as possible…
Perhaps this is of help. pyroSAR lets you download OSV files to the same folder structure as SNAP. With the latest version 0.12.1 files can be downloaded from GNSS thanks to @tyler-c2s and @system123. See here for documentation. This way you should be able to continue with SNAP 7.
3 Likes
Is the issue fully solved for SNAP 8.0 without any manual operation?
1 Like
I would like to know too about v 8.0 impact.
For SNAP yeas - I’m not sure whether the population of the official orbit site has finished yet or not.
the issue is solved at V8.0.3 version
1 Like
The orbit-files for all S-1 products should be up-to-date since 16-03-2021 and the previous anomalies have been fully resolved.
1 Like
It might be that I’m doing something wrong, but for me the GNSS api still doesn’t work for the majority of orbit files.
I use a (odata) query like this:
https://scihub.copernicus.eu/gnss/odata/v1/Products?$filter=startswith(Name, ‘S1’) and substringof(‘ORB’, Name) and ContentDate/Start le datetime’2020-01-01T00:00:00.000’ and ContentDate/End ge datetime’2020-01-01T00:00:00.000’
to find any orbit file that would be valid for 2020-01-01T00:00:00, but it gives me no results, just like many other dates. So apparently, still many orbit files are missing at least in the GNSS odata API.
BTW I checked the query by replacing the dates with ‘2021-01-14T00:00:00.000’, for which I know that there is an orbit file in GNSS odata, and then it works. So my conclusion is that the query is OK, but the API (or database behind it?) still misses the majority of the orbit files…
You are purposefully using a time-window of zero length?
It is not a timewindow of zero length, unless I misunderstood something. It is selecting orbit data with a start datetime that is less than or equal, and an end datetime that is greater than or equal then searched datetime. That should give me the orbit file(s) that have a valid datetime range (between ContentDate/Start and ContentDate/End) for this datetime, not? Or is there a better way to select the orbit files that are valid for a certain scene datetime?
Updating SNAP solved the problem with the timeout connection on SNAP toolbox. However python snappy continues to give the same exception. I guess it is still using the original source. Is there something i need to do to reflect the SNAP update changes into snappy package?
thanks
Hello to everyone,
Is there a way to solve this issue with an older version of SNAP? I’m currently using SNAP v6, via gpt. I tried to update via command line, as suggested by Marpet, but it didn’t work.
Having a look at snap/etc/snap.auxdata.properties the remote path for POE and RES is http://step.esa.int/auxdata/orbits, that is reachable, but SNAP keeps in trying to download them from qc.sentinel1.eo.esa.int, failing.
Is there a way to force SNAP v6.0 in downloading orbit files from the proper repository and avoiding qc.sentinel1.eo.esa.int? Or shall I update SNAP to v8.0?
Thank you!
You should update - a large number of bugfixes and improvements have taken place since 6.
1 Like
Actually, snappy should use the same modules updates as SNAP does.
There was an issue with loading module updates, but this has been resolved:
[SNAP-929] Modules not loaded when snappy is not started from the system drive - JIRA (atlassian.net)
Maybe you have some old snappy code?
You could check and compare the code shown in the following post with yours:
You find the __init__.py in the snappy folder. Where it is located, depends on your installation settings.