Ellipsoid Correction of ALOS PALSAR L1.1 4pol data in SNAP not supported?

the files are already written in PolSARpro format during the processing, no need for an export.

These tutorials will help you:

I tried importing a multilooked scene from Polsar into SNAP, but absolutely nothing happens, no error message - nothing. It doesn’t even work in the background or use processor power or hangs. It just doesn’t do anything.
I tried with the PauliRGB.bmp.hdr file.

I did also try with the T11 and 12 files just to see what happens and understandably I actually get an error message saying it doesn’t know its data type.

I’ll read up some more and see if I can figure something out

you are right, I get an error as well when I want to import PolSARpro files.

But in the new version 5.1.1 you can directly address the SNAP command from inside PolSARpro. Worked fine for me.

When I do that I get the “A problem occured during the geocoding” error

It worked well with dual pol though, I’ll try with quadpol from ASF a bit later as well

One my machine, the anti-virus software first checked the exe files of SNAP called by PolSARpro which lasted a few seconds. Maybe something similar happened at your side and caused a timeout. But this is only a guess.

I’ve tried two different machines and I get the same error. As of now I am pausing the efforts to get he quadpol to work and I’m focusing on the dualpol. Which at least geocodes the images, although the resulting image seems to be off by 500 meters or so. But that is another problem maybe for another thread if I can’t get it to work.

sorry to hear that…

Thank you for your help so far. I’ll have to revisit the quadpol soon though. But by then I might be able to have SarScape to try with. We’ll see if that works!

I did a quick test with ASF MapReady with the same dataset. It seems to be working fine until the terrain correction. Every error I get, even when selecting a DEM that absolutely matches the SAR-scene is: “Error, SAR and DEM datasets does not overlap”.

This intrigued me and therefore I tried with different DEMs but all with the same error.
In ASF MapReady there is a option to see the center of the SAR-Scene in google earth (There is a similar functionality in PolsarPro).
What it showed me was a place in the ocean to the west of Africa… my area is to the east of Africa! Northern Madagascar that is.

When loading the image in ASF MapReady it says:
“Approximate scene center latitude and longitude (-16.46, 44.72) appear outside the bounds of the image
…Recalculating from center line and sample instead”

I don’t have any solution but a part of the problem might be how either the geocoding is written in the ESA files OR how they are read. But since I get similar errors in PolsarPro, SNAP and ASF MapReady I guess it might have to do with how they are written or created.

I just tried it with QuadPol data from ASF Vertex and it works completely fine:

  1. Calibration
  2. Deskewing
  3. Multi-Looking
  4. Range Doppler Terrain Correction (left) OR Ellipsoid Correction (right)

From ASF it actually worked for me as well. I would be glad to use it, but the problem is that there is no quadpol over my area on ASF. My data is from ESA EARTHNET (https://earth.esa.int/web/guest/-/alos-palsar-fbs-fbd-and-plr-products)

I redownloaded some scenes but it didn’t really change anything.

I don’t know if you have access to any data from earthnet but it would be interesting to see if that would work for you.

Now I downloaded QuadPol data from ESA and i also received the error at the Terrain Correction step:

I noticed that the footprints of ESA data are not as long as the products from ASF. The ESA data are, as stated in the error message, already detected. I find this quite weird because they were downloaded as SLC products. Obviously, there are two kinds of SLC data in the ESA archive:

Solution 1:
(credits to @gusortiz who originally found this workaround).
If you don’t have much topography you can just use Radar > Geometric > SAR Mosaic with only one product. Uncheck “weighted overlap” and “normalize” and run.

This has basically the same effect as Ellipsoid Correction because no terrain is used for orthorectification. In my example layover and foreshortening are clearly visible and obviously not corrected. But at least geolocation of the whole product is correct.
So this only works for flat terrain!

I will test if the different SLC products make any difference in SNAP.

I just tried the ALOS products with narrow footprings and received the same error:

That means, ESA products of ALOS can currently not be processed in SNAP.

Thank you for testing, it is good to know at least!

My area is very flat, so I might be able to do the workaround. One question though, the SAR-scene is big so how far away from one flat area does higher elevation need to be for it to affect the geocoding of the mentioned flat area?

In the scene there surely are some higher elevations, not crazy high but at least 80-100 meter ones, will that affect it or is that low enough for it to be accurate? Anyhow I will test it out!

You will have to test. Just elevation is okay but strong relief will become a problem.
I also tested ASF mapready and can confirm that ESA’s ALOS products are not comatible with external DEMs (neigher WEGS84 nor UTM).

Looks like we need to update the reader @cwong

After some initial testing and processing two scenes, the accuracy seems good. I’m lucky my area is really flat! Thank you so much for all the help.