Thanks for your reply. The points are not really duplicates as they have different deformation rates (see below). So please can I ask why the points have only 4 decimal places for the coordinates? Is this a limitation of the data? Also, if I were to remove the “duplicates” using QGIS, what deformation value is used, i.e. the average? Is kriging the points an acceptable way to average and present results? Sorry but I don’t understand what is causing this, and how to best present the results:
First of all, how did you export the points from StaMPS and how many digits are used for the coordinates?
Referring to your first screenshot, I don’t get how the label is the same while the points’ locations are slightly different.
How many PS were exported in total?
Thanks for your reply. To answer your questions:
- I exported using the StaMPS-Visualizer.
- The export gave four digits for longitude (e.g. 174.7580), and five digits for latitude (e.g. -37.27453), so longitude is the problem
- I think QGIS stacks the points vertically just to make them visible.
- There were 835,000 PS total
Thanks again,
Mark
so many have the same x value but all have different y values. This explains the first screenshot you showed us.
I’m afraid there is no way to restore the actual location then, but you can merge them. For example, you could create one attribute based on both coordinates (with only four y digits, as you exported them) and then use the “Remove Duplicate Points” tool in SAGA which aggregate these points based on their location and computes an average for these aggregates.
I am afraid that you got some error while exporting the points in terms of decimals on the coordinates or some other issue.
I am pretty sure StaMPS can produce one PS per pixel, otherwise would be a Tomographic software.
A pity that you deleted all you can not export the PS again.
Thanks for your response. Please can you explain why there are only four digits for the longitude? Restore from what? In the future how do I obtain 5 digit coordinates for longitude?
We are targeting April 2020 so soon.
1 Like
deltaH is save (in radians/m) within the k value.
You need to convert to height using the k2q function, which has not the right values for Sentinel-1 platform. It is needed satellite height (~690km) and slant range first pixel timing… that it should be possible to get from metadata (I guess).
Please let me know if you manage to go ahead and if you plan to share it with us 
1 Like
Dear Mdelgado ,
I’m using snap2stamps for 17 images, in the step of( Coreg_ifg_topsar) , i have this result in each image,
IFG: isTOPSARBurstProduct = true
22%INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://step.esa.int/auxdata/dem/SRTMGL1/N36W001.SRTMGL1.hgt.zip
WARNING: org.esa.snap.core.dataop.dem.ElevationFile: http error:http://step.esa.int/auxdata/dem/SRTMGL1/N36W001.SRTMGL1.hgt.zip on http://step.esa.int/auxdata/dem/SRTMGL1/N36W001.SRTMGL1.hgt.zip
0
0
java.lang.NullPointerException
90% done.
org.esa.snap.core.gpf.OperatorException: 0
at org.esa.snap.core.gpf.graph.GraphProcessor$GPFImagingListener.errorOccurred(GraphProcessor.java:363)
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.cobbleFloat(PlanarImage.java:3254)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2181)
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.Operator.getSourceTile(Operator.java:461)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileInOneSwathFloat(TOPSARDeburstOp.java:895)
at org.esa.s1tbx.sentinel1.gpf.TOPSARDeburstOp.computeTileStack(TOPSARDeburstOp.java:802)
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)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.cobbleShort(PlanarImage.java:2951)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2172)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.datamodel.Band.readRasterData(Band.java:311)
at org.esa.snap.core.dataio.ProductSubsetBuilder.readBandRasterDataRegion(ProductSubsetBuilder.java:328)
at org.esa.snap.core.dataio.ProductSubsetBuilder.readBandRasterDataImpl(ProductSubsetBuilder.java:297)
at org.esa.snap.core.dataio.AbstractProductReader.readBandRasterData(AbstractProductReader.java:250)
at org.esa.snap.core.gpf.common.SubsetOp.computeTile(SubsetOp.java:270)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:80)
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 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)
at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)
Caused by: org.esa.snap.core.gpf.OperatorException: 0
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:432)
at org.esa.s1tbx.sentinel1.gpf.SpectralDiversityOp.computeTileStack(SpectralDiversityOp.java:463)
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)
… 35 more
Caused by: org.esa.snap.core.gpf.OperatorException: 0
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:432)
at org.esa.s1tbx.sentinel1.gpf.SpectralDiversityOp.estimateAzimuthOffset(SpectralDiversityOp.java:763)
at org.esa.s1tbx.sentinel1.gpf.SpectralDiversityOp.computeTileStack(SpectralDiversityOp.java:443)
… 38 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.esa.s1tbx.sentinel1.gpf.SpectralDiversityOp.outputESDEstimationToFile(SpectralDiversityOp.java:1308)
at org.esa.s1tbx.sentinel1.gpf.SpectralDiversityOp.estimateAzimuthOffset(SpectralDiversityOp.java:758)
… 39 more
Error: 0
– org.jblas INFO Deleting /tmp/jblas1979686758219654622/libjblas_arch_flavor.so
0
– org.jblas INFO Deleting /tmp/jblas1979686758219654622/libjblas.so
0
– org.jblas INFO Deleting /tmp/jblas1979686758219654622
[9] Finished process in 15.6482081413 seconds.
is there any problem???
Cheers.
I would say when the process is finished, there sould be no critical problem. But two things are worth checking
- is your data located outside the SRTM coverage?
- please open the coregistered product and create an RGB to see if master and slave are correctly coregistered
1 Like
Hello, sorry to write here, but I really need help to switch to external DEM. If it is not much to bother, could you point to it with an image? I would be very grateful.
Regards.
in the graphs folder of your snap2stamps directory, there are two xml files
If you open them with a text editor, you find the tag <externalDEMFile/> in line 26 (or 70),
replace it by
<externalDEMFile>...</externalDEMFile>
where … is the full path to your external DEM (in WGS84 and stored as a GeoTiff).
Save the graph and run the coreg_ifg_topsar.py script again (delete the ifg folder first). STAMPS then uses this DEM instead of SRTM.
2 Likes
Thanks for all your answers!!!. It worked immediately.
1 Like
It seems ESD is not recommended in graphs in the old scripts ,others words, is the new release about snap2stamps relative to snap7 ready? 
How it comes? ESD is in the old graphs which are totally compatible with SNAP6.
Next snap2stamps release will be compatible with SNAP 7, which only needs to update the ESD tags in the xml graph
SNAP8.0 is some weeks away after which we hope everyone migrates to it. We will involve you in 8.0 release candidate testing in case you are interested…? @mdelgado
1 Like
Sure! Let me know!
Always a pleasure to collaborate with you!
2 Likes
hi,
do you have any suggestion of where to put the slaves zip file folder and the bin/graphs folder ? such as master dim file(must create a new folder to put this single file).or put all the slave zip files in project folder directly,am I right?
the snap2stamps scripts require all slave zip files to be inside the slaves folder while the master (zip and pre-processed files) should be stored separately, e.g. in master.
The scripts then search for all products in the slaves folder and creates new folders in the same directory automatically.