yes, that is what I am doing already, thanks anyhow. Lets hope that the matter will be hardwired in a next version…
May I use the occaison to ask you another thing: To get up SNAP running, it take my rather strong and fast desktop-computer minutes and minutes, 3 or 4 at least. It has already loaded all the modules and then (half away through) does not move for all that time.
Is there a way to speed it up
that was helpfull too. I run windows7 and installed SNAP 5 (indeed OLCI mci is there – I like it) but it still took more than 2 minutes to get SNAP 5.0 up. On a Laptop Windows10 it takes 1.5 Minutes (something crucial in the settings while installing it?)
I attach the log file. Let me know if you find a point to speed it up.
Many thanks in advance
I can’t see any problem in the log, except that one file wasn’t found on our server. This is fixed.
But it should not slow down the start. On my PC SNAP starts within 8-10 seconds.
There are two things I could think of which might cause this trouble.
Are you behind a proxy-server?
Maybe this makes problems. Try to reconfigure it. After SNAP started go to Tools\Options. Switch to the WWW tab.
An other reason can be the 3D WorldWind component. To switch it of go in the Options dialog too.
Select General /World View and mark “Use flat Earth projection”
Also you can close the “World View” window. Instead you can open the “World Map” from View/Tool Windows.
I think it helped a little. I did the settings one at a time and started it after each change - but I am still at nearly 2 minutes waiting. Perhaps it is just the old OS I use (Windows7), as with Windows 10 it is much faster. I can live with it, will not change to W7 – too much hassel…
Many thanks for taking care of your users.
Regards and all the best
just to inform you that I solved my problem with the very long starting up of SNAP in my Window7 desktop (5 minutes to wait)
I found that in the directory .snap there was some 160G!! and my disk was often in red.
I desintalled SNAP and timeconsumingly deleted all large directories and files in .snap. Reinstalled SNAP 5.0 and did all the updates and that was it. Now SNAP opens in less than 10 seconds.
Of course I avoided now to click for all the “savety copies”.
Still, but how can you avoid to accumulate the dim and .data files?
We use S3 and S2 operationally and have a certain procedure. I try to use the GraphBuilder but I see that not all possibilities are included p.ex. FLH/MCI (in the thematic water processing) is not foreseen.
Will that come in a next version.
As a result of running a Graph I would like to have two versions of the same image displayed (and to start analysing them), a simple band combination and the FLH/MCI, resp. BandMath+Load. Is that possible to achieve this with the GraphBuilder and is there any manual available to get instructed (else than the one page of the Help)?
I don’t really get this question. Are you referring to the cache? But there should be no dim in the cache. Can you explain it a bit more detailed?
The problem with the Graph Builder is that it doesn’t support everything what is possible with operators and what is possible with the auto-generated stand-alone GUIs for the operators. The Graph Builder needs to be enhanced. It’s known since a while but I don’t know when it will be fixed. I’ll raise the priority for it.
But you can use these operators in graphs. You have to add them manually to the graph xml file and process them from the command line. Not very convenient but it works.
I don|t know if there is more documentation about the Graph Builder. Our documentation in general is pretty sparse. There is some documentation about processing which was originally written for BEAM. But it is still valid, when you replace BEAM by SNAP.
About accumulation of files using SNAP. Mainly under .snap in the directory var a lot of files accumulate becoming quickly many Gbytes. I am using S-2 and S-3 data daily and it fills my disk. How can we delete those files regularly? Moreover in the user-directory Juerg accululates .dim and .data files which I have also to control.
Thanks for your comments and advice on Graph Builder
you are right, it is all about S2-data in the cache. In fact cache is very deep until you reach the many files.
I try to set (as you advise) to delete cache at each start up (of the program or the computer?). But I can see that restarting the program it would not do it!
This means that processing each S-2 creates some 1.2 G. Perhaps an issue for the tracker.
And until a solution I have to delete regularly cache and also dim and data files.
Thanks for taking care.
and best regards
in one of the updates for SNAP 5.0.0 a bug has been introduced.
Using Open RGB Image Window and using the individual selection of bands the list presented to the user is strange: $2.B1, $2.B2…etc.
Selecting those it works, but when naming and saving such a RGB-Image-Profile it goes to rgb-profiles, and retrieving it from there the Error-Message appears “…not applicable to the current product”
Before doing all the updates this worked well.
using subset from a resampled image and exporting the subset to Geo TIFF, there is a message that one has to resamble (although the subset-file-name includes the term “resampled”.
After doing this resampling again, the …resampled_resampled image can be successfully exported.
I would suggest as a further improvement that when exporting a subset to “kmz” (View as Google Earth KMZ), the reprojection to lat. and long. should be done automatically. This avoids the steps: 1. the reprojection and 2. pre-display and re-work on the contrast.