Error when using the BandMaths operator via GPT

We are currently trying to switch over to the s1tbx version with snap 2.0. However, we are experiencing several problems when running graph-files via the GPT. First of all we noticed that the xml-tags for some operators have changed rendering our sets of test-graphfiles useless. Although annoying, this is something we can work out, but in the process of converting them to the new syntax we also found the following strange issue. When trying to execute the following xml via the gpt:

20151130T153026_20151129_20151117_2_COC_NESTGRAPH_3.xml (2.1 KB)

We get the error msg:

Error: The product ‘S1A_IW1_SLC__1SDV_20151129T161422_20151129T161449_008821_00C969_8CA5_VHBandMath’ already contains a tie-point grid with the name ‘latitude’.

Which is strange since we don’t specify anything regarding ‘latitude’ in this specific xml.

Finally, do the developers have any recommendations on how to verify if graph-file templates running fine in the old versions are compatible with the new release and how to efficiently change/convert them if they are not?

Best regards,
Sven.

Can you run the graph with gpt again and use the -e option. The error message should be longer then and maybe more helpful.

When you notice that the xml is not compatible any more, a good way to get new valid xml is to use the operator in SNAP Desktop and use Display Parameters from the File menu.
However, you are right, providing a guide how to convert the xml or even better a tool which converts the xml would have been good.

Hi @marpet,
thanks for your reply. Running with the option -e doesn’t seem to give more info. The full exception output to screen reads:

Error_MSG.txt.txt (3.3 KB)

Regarding the procedure you suggest to convert existing graph-files to SNAP2.0, it doesn’t really help us since we also use Operators not available in the GUI, like “Merge” and often if your xml syntax has some syntax error, the GUI doesn’t really provide useful feedback. In this respect it would be very useful if the GPT would report, after parsing the xml, which node contain errors and preferably even the name of the unknown or missing tag…

Best regards,
Sven.

The additional stack trace was helpful. Thanks for this.

This is really a bug. I’ve created a ticket for it in our issue tracker. (SNAP-350: BandMaths operator fails copying the latitude tie-point grid).
Currently I’m not aware of a workaround. I think we have to take care soon.

Hi @Marpet,
I just saw that the status of the issue SNAP-350 changed to resolved. However, we have problems to locate the updated source-code for this change. We would like to get it ASAP and recompile the toolbox ourselves from source. Is this possible?

Yes, you can build it your self.
The change is in this commit on the master repository.
I think we will release an update soon which will include this change. Probably this year.

Hi, thanks alot!. With this Issue out of the way, there remains on other issue we reported that is holding us back to do our automated processing. Since it seems to be also related to the GPT perhaps you know about it or its status? Is there perhaps also ticket for this in GitHub that we can monitor?

Sorry I don’t know the status of this issue. maybe @lveci knows it.
On GitHub we don’t manage the issue.
We have a Jira instance running where we manage issues…

Hi @SvH,

there is an update of SNAP. This should fix the tie-point grid issue.
Just go to Tools/Plugins and then “Check for Updates”.

Marco

Hi Marco,
We had compiled from source already and it worked indeed! We are now just waiting for a fix on the empty slave bands after applying BackGeoCoding via gpt, before we can switch our processing chain to the SNAP2.x

Best regards and thanks for the support,
Sven.