Hello forum!
I have been working with snap python for a while but mostly with S2, right now I am trying to do interferometry with S1, but I found myself in trouble when doing the back-geocoding.
The images selected are SLC of the same (identical) area & location, with ~2 weeks of difference.
The point is that the back-geocoding returns me two different 2 errors:
- For the ACE DEM and the CDEM the error is the following:
The error of NullPointerException is an error that I don’t understand. As you can see in my debugger, the error is when writing down the BEAM DIMAP file (I guess all the processing is fine, therefore)
- For the Aster DEM there are no errors but it returns me an empty (0.0 values!) slave image (the master is ok). Why?
(Bonus error) For the SRTM the error is the following: “org.esa.snap.core.gpf.OperatorException: Entire image is outside of SRTM valid area. Please use another DEM.” - Ok, I got that one.
The region I am working is the north Baltic sea, specifically near Oulu, Finland.
Please help me understanding these errors. In the image I posted you can see the arguments and the function “back-geocoding” for further information.
Thanks a lot! That’s a great forum!
Joan
p.D.: I am using Snap 7.0 and Python 2.7
Please take a look at this nice example,
SNAPPY TOPSAR Coreg Interferogram script from Alaska Satellite Facility (ASF) Distributed Active Archive Center (DAAC)
Source: https://git.earthdata.nasa.gov/projects/ASR/repos/asf-daac-script-recipes/browse/snappy_topsar_insar_share.py?at=5e0fa89bb1a3de4640771d75df57e4d897042184&raw
Concerning THE DEM , Doese SRTM 1sec , covers your AOI? IF yes please give it try,
2 Likes
Hi Falahfakhri!
Thanks for the quick reply, actually part of the development of the script was based on this programme from the ASF, so args and inputs are the same.
As you can see here SRTM1 covers all the Baltic Sea:
Aster is a global post processed DEM so it covers too… But the errors are what I don’t understand…
I already tried with SRTM 1sec and the error is the same than commented above:
1 Like
Could be the matter is the DEM projection, reproject it (if not!) , to EPSG:4326
Also please check up the same process in SNAP, testing all your DEMs
1 Like
Very low resolution DEM if perfectly enough for back-geocoding - you can ue for example the GETASSE30.
For Aster you need to download the DEM manually as there is no auto-download option.
1 Like
So far, in Snap I had the same errors. Regarding reprojections, aren’t they the same projections (S1 products from Copernicus Scihub vs. DEMs in Snap)??
1 Like
The auto download DEM, should be EPSG:4326,
Would you please to share the identifier names of two products, I could test today late,
1 Like
Hi,
With getasse30 the problem is the same than with ACE and CDM
You will see the null pointer. Regarding the auto-download, I only used DEM that have the (Auto Download) activated (Aster in SNAP 7.0) has it.
Maybe this happens because of the Snap 7.0?? Would it work in Snap 6? I remember learning a bit of interferometry with Snap 6 and this did not happened…
Thanks a lot Falahfakhi, the IDs are the following:
‘S1A_IW_SLC__1SDV_20190226T045644_20190226T045711_026096_02E941_9C24’
‘S1A_IW_SLC__1SDV_20190202T045645_20190202T045712_025746_02DCC9_A94B’
I have just seen that Getasse30 DEM seems to work in Snap but not with Snappy (kudos for @mengdahl), all the others have the problems commented above.
1 Like
Dear Joan,
I checked up in SNAP, actually the problem as you see SRTM 1sec and 3 sec , both they don’t cover the AOI,
However, GETASSE30 covers the AOI,
Coming back to python script, you have two options, the first one is to use GETASSE30, Or/And to download other tile of DEM, covers your AOI, and you could check up the projection in SNAP using this icon,
the highlighted one,
It’s simple to reproject in SNAP from Raster—>Geometric Operation—>Reproject
Also the error, you posted, refers to other
I don’t think this is related to DEM, while you used GETASSE30, but might be it should be in upper case DEM = ‘GETASSE30(Auto Download)’ , without indentation between 30 and the bracket,
Take a look at similar problem in this thread, Source of the thread
Please let me know if it helps,
1 Like
Hi Fakri!
Thanks for the complete answer!! (Kudos to you for your work!!). I have seen that Snap works well with Getasse 30 but same processing in Snappy is giving the same error of the Null Pointer Exception.
I have tried changing the argument of the function to GETASSE30(Auto Download) and Getasse30(AutoDownload) it didn’t work… neither GETASSE30 (Autodownload).
Finally, regarding the reproject, before reprojecting it should be Terrain Corrected / Elipsoid is it true? I am thinking about the pipeline. Should I put terrain correction in the first place before the TOPS Corregistration?
Thanks again for your help!
Actually not, TC, should be the last step, But if you search within the STEP FORUM, you’ll find a lot of similar error of java.lang.NullpointerException there are a lot of reasons related to this error,
What do you think if you could split your script as steps in SNAP, and then check up in which step is the source of the error?
By the way, Did you select the same sub swath and bursts in both images?
I suggest now only to select the IW1 and one burst, and check up your script!
1 Like
More or less this is how I do it. So in my script I have different steps according to Snap operators. For interferometry, I select subswath (the burst will be an extra, thanks for the feedback), then I apply the orbit and finally the back geocoding.
Every output is tested, selecting subswath and applying orbit always deliver products that Snap can represent. But then, in back-geocoding is where the error is. Maybe this is more a bug from Snap python than an error…
Perhaps @marpet or @ABraun can share their expertise too (do they now any user in the forum that works with Interferometry in S1?)? Maybe this helps…
Have you considered having your python-script to set up the graph in .xml and then call gpt? Performance should be better that way.
1 Like
Using the command line of Snap… sounds interesting too, I will check this, aside from the py script! Thanks!!
Hi Forum,
Problem solved, just that you can’t put the string ‘(Auto Download)’ in the DEM Model input!
So now the back-geocoding worked!!
Thanks specially to @falahfakhri for all the help, for any question I am at your disposal!
Best
Joan
No problem, I’m happy to help, and more happy that your problem is solved,
But do mean this line
$ parameters.put(“Digital Elevation Model”, “SRTM 3Sec (Auto Download)”)
Should be $ parameters.put(“Digital Elevation Model”, “SRTM 3Sec” )
Or in your case $ DEM = ‘GETASSE30(Auto Download)’
It should be $ DEM = ‘GETASSE30’
def backGeocoding():
### backGeocoding
global prods
global targetbackGeo
parameters = ""
parameters = HashMap()
parameters.put("Digital Elevation Model", "SRTM 3Sec (Auto Download)")
parameters.put("DEM Resampling Method", "BICUBIC_INTERPOLATION")
parameters.put("Resampling Type", "BISINC_5_POINT_INTERPOLATION")
parameters.put("Mask out areas with no elevation", True)
parameters.put("Output Deramp and Demod Phase", False)
if iDebug:
for u in prods:
print u
targetbackGeo = GPF.createProduct("Back-Geocoding", parameters, prods)
if iDebug: print "Back-Geocoding working"
1 Like
This is wrong, the guys from the ASF forgot to debbug it xD Actually the string name should be ‘SRTM 3Sec’ if not, you have the nullpointer error
With regards my script, I am compiling the functions of the coregistration (Split, orbit file & back-geocoding) is it worth to include also the ESD and the Azimuths shift? Is this a must for an InSAR corregistration (my target is to make a quick MVP with the “must be” operators).
Thanks!!
Yes sure, Please take a look at these posts explain the reason of including ESD in S1 Corr.
Source of the post
Source of the post
Yes, For S-1
I think it’s worth to sharing your script, once it’s ready, if you like and that possible,
1 Like
Perfect I will take it into account! Awesome quick reply, thanks a lot.
Regarding publishing the script, well I see it complicated since it is for a third-party…
