S1 SLC 6 day coherence products creation after SNAP 8 upgrade

snap Problem Reports
#1

Hiya,

Is anyone generating 6 day coherence products from S1 SLC? After updating to SNAP 8:

  • There is an orbit truncation limitation on the 30 days period
  • There is an error downloading and placing the orbits on the right folders
  • After sorting this out manually, we seem to have an issue with the glibc library and GDAL 3.0.0 pre-installed on SNAP

If this sounds familiar please let me know!

#2

are you sure you have installed all internal updates? Your version should then be 8.0.4. In this version, the new orbit location is updated.

#3

Thanks! Have been using 8.0.0, and 8.0.5 for the install4j.

We bypassed the orbit issue manually though and then the generation got stuck in the libraries. Have you managed to produce 6 days products?

#4

I don’t see how this is related to orbit information.

#5

We believe it is not, indeed. Two different issues. Firstly downloading the orbits and place them right, which we do manually anyway, then doing the processing. This is when we get the glibc library error → GDAL 3.0.0 precompiled on SNAP 8.0.0 does not get executed on Alpine due to the non-compatibility of the library “musl”, which should take over “glibc”, unavailable on Alpine

Please note:

  • GDAL 3.2.2 cannot be used (versions over GDAL 3.0.x are not compatible with SNAP v8.x)

  • GDAL versions 3.0.X do not link with libgdal.so.26

Can you elaborate on 8.0.4? Did not find a release note. Is there a .sh? Maybe something else than the orbits issue was fixed? And for this, is it both the 10 items truncation, the 30 day limitation and the download and placing issue?

Thanks a lot!

#6

I’m not a developer so I’m afraid I cannot help much here. Maybe @lveci or @jun_lu can comment on this?

#7

Have you considered building GDAL 3.0.4 on your system? Since GDAL has many configuration options for supported formats, you should try to select the same options used for SNAP’s GDAL 3.0.0. You will need lots of packages with the development files for the libraries. Most distros have a way to install the packages needed to build a given package from source, which should get you the majority of required library packages.

#8

Thanks, we may try that.

I was hoping it was a more known issue with libgdal.so.26, but we´ll keep you psoted on our progess. If any developer can give us a hand it would be very much appreciated.

#9

It is not unusual with 3rd party packages to find that the binaries require runtime libraries that aren’t available on a given linux platform, so recompiles are often needed (along with some code patches

OSGEO grasswiki has lists of packages needed to build grass on alpine. That should cover the majority of GDAL requirements.

#10

We tried first building with CentOS since it includes the glibc library natively, and it seems to work :slight_smile:

#11

You should mention your platform. It is normal to have problems with library versions if you attempt to use a too old linux version with newer software. In general, the best solution is to upgrade the OS. If upgrading is not possible, you can try rebuilding the problem binaries, but there may be other issues building the software on old platforms such as lack of support for current language standards (C++ often needs a recent compiler), so you end up backporting and installing a current compiler from source.

#12

The problem was with Alpine OS, as mentioned. Then, the SNAP upgrade function seems not to work, either. We required a lot of manual work, on top of the orbit issue (not sure how to get to 8.0.0.4 but in 8.0.0 is not working + the search is fixed to 30 days and the orbits results truncated). We are focusing on that, may list an extensive report once production is fully running.