I have recently installed SARproz and I want to know how can I import a DEM which I have produced with a TDX bistatic pair in SARproz?
the default one is SRTM. I tested the first process with sw’s default DEM. but the area which was defined by cursor was not the same as my images scene. it was spread from west and didn’t cover the eastern part of my images. The case is a bridge over a lake. so most of the pixels are water pixels.
and something else. it seems that the main master and slave images that are shown in SARproz are not the same as the original images in line and pixel sizes. I have red images with DORIS software and the scene is larger there. Does SARproz crop some part of images automatically?
1. in the software manual, you can check how the software can ingest external DEMs at the paragraph “18.104.22.168. External DEM Selection”
2. probably the easiest way for you is to create a geotiff DEM (with an other software) and import it in Sarproz
3. anyway Sarproz can manage TDX bistatic pairs and respective interferograms. You may want to consider it.
4. your other questions make me thinking: did you extract and process the full frame of your datastack or a smaller cut?? In the SLC data processing a 20km radius is set by dafault. But you can check the “max area” flag and process the full frame data. Did you visualize the footprint and the Master area in Google Earth?
5. Sarproz by default uses the orbital infos contained in the data you imported. Sarproz tries to avoid black areas in your images, so, it searches for a common area (based on orbital data). This is the only automatic crop.
6. Orbital data can be inaccurate. So, it is not surprising if you can see a shift between SAR data and DEM (you should have seen the shift also in SLC data processing, by plotting the footprints). The GCP selection module is exactly aimed at solving this misalignment. Please read the manual and look at the tutorials.
regarding the out-of-area crop (the first question), I have the same experience. It seems to me that probably when reading the dataset, no heights are considered, and the crop is then moved to east/west (different for asc/desc). It helps to crop a bigger area or just put shifted geo coordinates. In the next steps (GCP, geocoding etc.), the heights are already considered.
The height is considered. However, what is used is the height coming with the SAR image, which is usually 1 value for the whole image. We can work at improving it. But we would need to get 2 sample images in which the shift is present and significant.
Ivana, could you share 2 images out of your case?
Ivana: thanks to your case I inserted a couple of minor corrections to provide a better match between the SAR and geographic coordinates in the Master area selection, SLC module. Pcodes are online, compiled version for windows is uploading, and the linux compiled version will be available in the next hour. You can try if you want and let me know.
I checked the matter raised by Farnoosh but there is nothing wrong: the sw tries to avoid black areas (based on orbital information), so, this is the reason why the crop of the full frame is slightly smaller than the original size of the image (around 1%, depending on orbital alignment).
The DEM looked like having no problems and being correctly aligned.