@ABraun, sorry I have found when you select the external dem…
No, I can confirm that I haven’t selected it.
okay. This would have been an explanation for the changed values at least 
1 Like
@ABraun, waiting to have help from @lveci or @jun_lu, there are also other two questions and I hope you can help me with them.
- as said, to cut off the sea I have used Land/Sea tool considering the SRTM 3sec dem. The obtained interferogram is
now to all the pixels belonging to the sea is assigned the value 0.0 as phase and not NaN. After the unwrapping step, also to the corresponding pixels, the unwrapped phase is assigned 0.0 and not NaN. So my question:
All these values (0.0) could interfere in some way during the unwrapping analysis?
Moreover, when I apply the phase to elevation to create the InSAR dem, it assigns to all those pixels with unwapped phase equal to 0.0 a height values between 93 and 94 m.
- If I try to mask the image with Terrain-Mask tool and I use my external dem to cut the image only in that area and to process it with SNAPHU, none mask is applied and I have another band Terrain_Mask completely black.
Do you any idea about that and if there is another way to select only the area covered by my external dem?
Thank you in advance.
S Savastano
I don’t think so. The idea behind is to avoid that irregular patterns over the sea will distort the unwrapping of coastal land areas. So if the Phase To Elevation operator then imputes the elevation values of the external DEM, this is just a mathematical process, but not affecting the quality of the land area.
I think newer versions of snaphu allow the integration of better masks, but I have never tried it so foar. The SNAP terrain mask only uses SRTM 3Sec and my last try with it also produced a black image.
But you can add SRTM 1Sec data to any product (right-click > add elevation band) and use sea pixels for masking using the valid pixel expression of the band properties.
1 Like
Hi @ABraun,
sorry to reply so late.
wow, that’s an interesting tip! I will let you know as I have some update with results.
I have another question and I hope not to bother you too much.
As you can see from my external DEM, my ROI covers a very small part of the SAR image. Looking to the next screenshot, only the area in the black rectangle
If I subset the interferogram only to that small area, is it still possible to unwrap the phase using SNAPHU? is it still possible to get reliable results with so few pixels or SNAPHU demands to have more pixels to guarantee better results?
S Savastano
I think it could help to reduce the area, maybe not strictly to the black extent, but a little larger. It will need some experimenting with the unwrapping parameters (no tiling required then = 1 cols/rows, no overlap either), but I would expect that the chances for unwrapping errors are lower then.
1 Like
Hi Andreas (@ABraun),
unfortunately also reducing the ROI the problem with the values change for my external DEM after the Terrain-Correction is still there and the InSAR DEM values are too different from the real scene under observation.
I’m working now with other suitable image pairs with less noise from low coherence areas and artefacts from the unwrapping to get a better elevation map (with values more similar to the real scenario).
However, I continue to think that is a bug of the Terrain Correction tool and so I’m asking your opinion.
Is there a specific procedure to submit a request of a bug fix to the developers for a new release? Is it better to open a proper new topic about it?
I’m not used in this procedure and I don’t know very well the rules of our community on this matter.
Thank you in advance for your guidance.
S Savastano
The developers are currently busy with the release of SNAP 8, but as this is obviously a bug I’m sure they will respond here once there is time and include it in a bug fix update.
1 Like
Dear @ABraun
I have some questions regarding using DEMs in SNAP.
We use DEMS in several steps in SNAP like radiometric terrain flattering, interferogram formation , geometric terrain correction and so on.
My questions:
- If we used an external DEM in ‘radiometric terrain flattering’, can we use another DEM when we want to do geometric terrain correction?
- As I can see here, you mentioned that ‘DEMs must be projected in WGS84 (not UTM)’ to use as external DEM…actually I did not get your point because when we select even:
WGS 84 then it is ‘AUTO:42001 - WGS 84 / Auto UTM’ and has UTM
Or below one is based on WGS 84 but it has also UTM
EPSG32633: WGS 84/UTM zone 33
So, what do you mean with ‘DEMs must be projected in WGS84 (not UTM)’ exactly?
And why?
In many cases, I used DEMs in UTM but I did not get any error by SNAP.
- For example someone gave me an DEM with EPSG:3067
ETRS89 / TM35FIN(E,N) - Finland - EPSG:3067
Do you mean I should first, re-project it to WGS 84 and then use it as an external DEM?
Shall this is important only for terrain correction or it is important for other steps that we use DEMs like for interferogram formation and geometric terrain correction?
Technically, you can switch between DEMs for the different tasks.
WGS48 (EPSG:4326) is a global coordinate reference system based on latitude and longitude in degrees. Any external DEM must have this projection.
UTM is divided into differnent zones and based on meters. The “WGS84” in the name only refers to the ellipsoid underlying this coordinate reference system, so this is a bit misleading. SNAP doesn’t accept UTM-projected DEMs. ERRS89 is another ellipsoid, in your case combined with a finnish coordinate reference system - also not possible in SNAP.
A good explanation of the difference is given here: https://theconstructor.org/question/what-is-the-difference-between-utm-and-wgs-in-gis-software/
Thanks @ABraun . This is very important note 
.
Now, I changed my DEM from EPSG:3067 to WGS48 (EPSG:4326) to use ass external DEM in SNAP. I did this by using raster—projections----wrap in QGIS.
I tried to do it in SNAP but I think SNAP cannot open big files (my file has 6.26 GB), so I did in QGIS.
Another point:
You also mentioned that SNAP doesn’t accept UTM-projected DEMs but I remember, I gave external DEMs as external DEM to SNAP but it did not give me error.
OR,
Maybe you mean it does not give error but results are not accurate?
Good job on reprojecting the data.
Can’t tell why it worked with UTM in your case, but if you want to go sure and avoid errors, DEMs with geographical coordinates should be used.
1 Like
Dear @ABraun
There is something strange in my result after terrain correction.
When I want to export my image as geotiff, then ‘history’ is missing.
And then it exported geotiff but when I want to open it, then it says:
Actually, it made a geotiff with 0 kb and it means it is empty.
I do not know what is the problem.
Dear @ABraun
I tried to apply all processings from the first step (I mean ‘apply orbit removal’) but I understood that ‘history’ is missing even from the first step and I do not know why (1 in below image).
I tried to do ‘apply orbit removal’ over another product (2 in below image) but it is fine for it.
I do not know what is the reason…
The GeoTiff format cannot store all metadata, maybe it was lost after conversion.
then you have to go one step back and work with the BEAM DIMAP format.
Hi everyone. It’s now November 2023, and the problem mentioned by @s.savastano persists, i.e. the “raw” external dem has a different range from the one resulting from the terrain correction function (i.e. the “elevation” band, not “elevation_VV”), although we would expect the range to be the same. I tried this with some VHR DEM that I have as well as copernicus30m.
Ps. I am using SNAP 9, and I tried everything mentioned above, i.e. reprojectig the external dem and checking/unchecking gravitationalal earth model. I also tried resampling to 30 meters in the case of the cop dem.
Can you point to the post describing the problem? …this thread is getting too long…
Hi @mengdahl, thanks for the quick reply. The issue I am facing is the same reported by @s.savastano here.