Problems with stackStripMap steps 5 and 6

Added by Joaquin Escayo 5 months ago

Hello there:

I'm trying to do a Envisat stripmap processing with the latest version of ISCE and I have some questions regarding some steps (mainly steps refineSlaveTiming and invertMisreg), others I were able to fix it by reading the forums.

In the refineSlaveTiming step I found out that there is a lot of "Bad match at level 1" messages in the output, while in version 2.3.2 there was almost not this type of messages. First I thought it was a compilation problem and tried multiple combinations of python versions, gdal and other dependencies but today I tried with the anaconda 2.3.3 version and got the same results. I found this message is related to ampcor module, and it is also present in Sentinel processing (with topsStack). I attached screenshots from both versions.

Also in the invertMisreg (step 6) I am getting errors in some pairs, not all of them but some seems to crash the program as it return not expected data, see attached file. This seems to occur in 2.3.2 and 2.3.3 version.

Thank you !!

isce_2.3.2.png (298.7 kB)

isce_2.3.3.png (281 kB)

step6.png (883.7 kB)


Replies (14)

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

Just change the argument to flatten to 'C'. This is a change in numpy API. 'C' was always correct - 0 used to work before and no longer works.
There is not enough information to comment on other ampcor related issues. The first one is a warning and has no impact.

RE: Problems with stackStripMap steps 5 and 6 - Added by HY Chen 5 months ago

Dear Joaquin and Piyush
Thank you both for your generous help! I have already solved problem that mentioned in http://earthdef.caltech.edu/boards/4/topics/3303,
and follow your work, In ./run_files/run_6_invertMisreg, I fixed invertMisreg.py in line74 : return azCoefs.flatten(order = 'C'), rgCoefs.flatten(order = 'C')
However, A new error occured:
KeyError: 'azpoly'

error.PNG (72.9 kB)

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

You will have to debug this by loading the shelve files individually and checking. You will find plenty of examples in python scripts or by googling.
Either the ampcor runs failed and never added this information or there was a big version change - you are possibly mixing two versions when running the processing jobs.

RE: Problems with stackStripMap steps 5 and 6 - Added by Joaquin Escayo 5 months ago

Thank you for your replies.

I did a test and got the same results as Chen, the first error is fixed but 'azpoly' error arises. I'll try to debug it and comment the results.

Joaquín

RE: Problems with stackStripMap steps 5 and 6 - Added by Han Bao 5 months ago

Hi Joaquín

May I ask if you are processing RAW data or SLC data?

RE: Problems with stackStripMap steps 5 and 6 - Added by Joaquin Escayo 5 months ago

Hi Han!

I'm using Envisat SLC data in both tests that I'm processing right now. Since it is easier to get I usually prefer SLC data.

Joaquín

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

Sounds like there were errors in ampcor that you are trying to fix in the next steps. Would be best to trackdown issue where azpoly was not even populated in the file

RE: Problems with stackStripMap steps 5 and 6 - Added by Han Bao 5 months ago

I see. Then I won't be able to help. Sorry about that. I've only processed RAW data (ERS and EnviSAT) with ISCE.

Good luck!

Ps. Just for your information, as far as I remember, if using ISCE, processing EnviSAT and ERS data from RAW will generate better result than starting from SLC data since the doppler conversion (from zero to native) can somehow contaminate the result. (Piyush, please correct me if I'm wrong).

Han

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

Envisat SLCs should not be a problem. This was an issue with old processors which assumed focusing deskew was same as zero doppler. Using SLCs from ESA should not be a problem.
We have processed numerous stacks with SLCs from ESA. Raw data at present is mostly beneficial only when you want to stitch long tracks.

RE: Problems with stackStripMap steps 5 and 6 - Added by Han Bao 5 months ago

Hi Piyush,

Thanks for the information. Lesson learned.

Han

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

One issue could be specifying the geometries.

1. When starting with RAW - ISCE focuses data to native doppler and -n flag needs to be specified
2. When using SLCs from ESA - these are in zero doppler system and you should not use the native flag

If you turn on native geometry flag when working with zero doppler data - that would cause large misregistrations and errors.

RE: Problems with stackStripMap steps 5 and 6 - Added by Han Bao 5 months ago

Thanks, Piyush. Really good to know that. But I don't recall that I've ever specified the -n flag when processing the RAW data.....
Is that a problem?

RE: Problems with stackStripMap steps 5 and 6 - Added by Piyush Agram 5 months ago

If you started from raw and you dont see flags like "native: True" in the config files for topo / geo2rdr - then the geometry is being interpreted wrong.

RE: Problems with stackStripMap steps 5 and 6 - Added by Han Bao 5 months ago

Found related information in (e.g.) the file PICKLE/topo.xml and PICKLE/geo2rde.xml:

'<'property name="mastergeometrysystem">
'<'value>Native Doppler'<'/value>"
'<'doc>zero doppler or native doppler'<'/doc>
'<'/property>

Also since all of my igrams look fine, I guess they were processed correctly. So the "native doppler" should be added automatically I guess.

Han

(1-14/14)