Hello
I Have this DEM and I am wondering which one is correct
by using Phase to elevation or phase to height
it is the same area with same data just one by elevation and the other is to height
if you look well there is a deference between ?
@squeakus was the phase to elevation working for you now? Because I have the problem that the hole process runs without an error, but the DEM is just not looking like a DEM and the values are realy funny (for example - 6000 to + 6000 and I am not working in Himalaya region ) I also tried the phase to height but this was not running but also did not show an error, just nothing happened. I tried this with a lot of different S1 pairs and also with other radar data like TD-X and TS-X, but always the same issues… And of course I tried different versions of SNAP (3 / 4/ 5).
you can add the elevation band to both products (right-click on the bands) and then calculate the difference. Generally, I would say that phase to elevation performs better than phase to height for DEM creating purposes.
Did you have a look at your coherence raster? Is it good?
How large is the temporal gap between your images?
Can you please send a screenshot of the DEM and the steps you performt in the corresponding order?
In my case (I’m working in an area of Indonesian rainforest) even the coregistered data is not looking good, this is due the high temporal baseline of 12 days (in case of my Sentine-1 data). My coherence is too low, by around 0,3 for the vegetated areas.
But after I realizd this issues I was trying a test data about Pico de Fogo in Cape Verde, a vulcano with no vegetation, which was used in the SNAP TOPS Interferometry Tutorial (Veci 2015). I just wanted to know, if the phase to elevation tool is working in an area without issues due to vegetation, the coherence is much better here (displayed the stack as rgb and it is looking mostly yellow, so this should be fine) but the DEM results look just as bad.
I did the following steps:
-Coreg.
-Interferogram (incl. coherence)
-Deburst
—Used a subset since here to reduce processing time
-Goldstein Filter
-Snaphu exp.
-Snaphu imp.
-Phase to elevation:
even if coherence is high, there are still error sources like atmospheric disturbances which affect phase differently than intensity and unwrapping. A quite successful example (at least at first sight) of S1 DEM processing is shown here:
Well I did the same steps, but it could be an error of the to small baseline in my case. Yesterday I repeated my processing for a TD-X/TS-X CoSSC image (so no temporal decorelation and an effective baseline of 163m) and this one is looking much better as you can see here:
Just the three artefacts are strange, I got them in my unwrapped pase the first time.
I will play around with different baselines, maybe that is helping!
Thank you for your time
yes, Sentinel-1 is no competition to the quality that can be achieved with TanDEM-X data. Looks great.
To get rid of the square-ish artefacts, you can change the number of tiles in the unwrapping config-file and compare. I assume that they are related to these tiles somehow.
Thanks, I downloaded mint 64 and VMmare player, but there is no file “src / snaphu_io.c file”. When you download separately the archive snaphu-v1.4.2, there is “snaphu_io.c”. But how do I unwrapping the phase? Need to install snaphu-v1.4.2?
After the unwrapping phase scan for Sentinel-1, we obtain the values of the displacements of the earth’s surface, they are measured in centimeters or meters?
i am facing some problem (Java.lang.NullPointerException) while generating DEM through Interferometric->Products->Phase to Elevation even using SNAP 5.0. (latest updated) on OS windows 8.
If i go for Interferometric->Products->Phase to Height, nothing is happening. @squeakus did you get the solution for this problem?
Error is:
org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:421)
at org.esa.s1tbx.insar.gpf.PhaseToElevationOp.computeTileStack(PhaseToElevationOp.java:336)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:85)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
Caused: org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
at org.esa.snap.core.gpf.internal.OperatorExecutor$GPFImagingListener.errorOccurred(OperatorExecutor.java:376)
at com.sun.media.jai.util.SunTileScheduler.sendExceptionToListener(SunTileScheduler.java:1646)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:921)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:407)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:393)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:73)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
[catch] at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)