Ask a question
Enter questions and answers or comments here (you must be registered and logged in). All registered users are welcome to add to this page. Please subscribe to this page if you want to receive e-mail notification of new questions or answers.
Contents
- Ask a question
- How do I become a member of ROI_PAC Wiki?
- process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
- make_raw.pl fails
- Where can I get PRC orbit data for ERS2?
- Too few points left after culling error
- Installing on a Mac
- Problem with test data
- Using state vector info for ENVISAT
- Why was ROI_PAC only designed to process raw data?
- Processing Seasat data
- Using ESA orbits for Envisat
- YMAX bigger than FILE_LENGTH?
- How to skip multilooking ?
- How can I process a subset of my SAR image?
- Problems selecting an area of interest
- Compiling problems
- Processing TerraSAR-X SLCs?
- Using make_raw.pl with CEOS data from EODC and other ground stations?
- PALSAR pairs which won't register?
- Simulated SAR image (from DEM) contains stripes
- Can Sky Telemetry Format be processed?
- How to convert unwrapped phase to range change?
- How can I geocode the wrapped interferogram with geomap.trans?
- Question about ROI_PAC test run
- Radiometric correction/calibration on the *.amp files?
- How can I use a DEM in UTM projection?
- Can't visualize date.slc file
- Can ROI-PAC work with different client processing at the same time?
How do I become a member of ROI_PAC Wiki?
1. Create your user account (register). It is strongly recommended to use FirstnameLastname (with no space between words--a WikiName) as your username.
2. Send an email to FariaChowdhury or EricFielding requesting to be added as a member. Please include some information about your interest in ROI_pac and tell us what username you have registered.
You need to do both of these steps if you want to be able to modify pages other than this question and answer page.
process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
- When I execute process_2pass.pl, I get the above error. Below is the complete output. I am not sure what is it that I am doing wrong. Please advise.
abid@abid-laptop:~/Desktop/ROI/ROI_PAC_3_0_1/run1$ process_2pass.pl param.txt +process_2pass.pl Read the inputfile +process_2pass.pl Define Variables +process_2pass.pl Go from raw to slc to int and cor (also flattens with orbits) Usage: raw2ampintcor.pl Function: Goes from the raw ERS data to interferogram and correlation images *** Last Update Aug 18, 1999 *** For more info see http://roipac.org *** This software is part of the ROI_PAC suite. *** Licensed software, not for general distribution. +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
- Please advise.
You need to add the required information to the "param.txt" file. See the ROI_pac Internals document for explanation of the parameters.
make_raw.pl fails
make_raw.pl fails, please help
- I am using roi_pac for ER01 and ER02 images and when I run the command make_raw.pl it says the state vector.pl failed in make_raw.pl. Please help. The error message is:
abid@abid-laptop:~/Desktop/ROI/ROI_PAC_3_0_1/run1/19931124$ make_raw.pl ODR SARLEADER19931124151441 19931124 +make_raw.pl Checking I/O Creating 19931124.raw Creating 19931124.raw.rsc +make_raw.pl General definitions +make_raw.pl Getting facility name +make_raw.pl Finding reference counter, pri and prf counter read: 812 swst offset read: 214 +make_raw.pl Reference counter = 812 +make_raw.pl Checking line number +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/new_parse 11644 210 4 1 IMAGERY19931124151441 tmp_IMAGERY.raw 29000060 +make_raw.pl Reading the leader file +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/leader2rsc SARLEADER19931124151441 /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/multibuild-100118-1757/installs/share/roi_pac/format_leaderfile_D-PAF tmp_IMAGERY.raw.rsc +make_raw.pl Reading the imagery file +make_raw.pl Setting the starting range +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/delay_shift tmp_IMAGERY.raw tmp_IMAGERY.new shift.out 214 812 11644 412 11636 0 0 shifting line 0 shifting line 10000 shifting line 20000 +make_raw.pl Writing the imagery resource file +make_raw.pl Reading state vectors in SARLEADER's header, Building hdr_data_points_19931124 file +state_vector.pl getorb failed in state_vector.pl +make_raw.pl state_vector.pl failed in make_raw.pl
- Thanks.
You need to have the University of Delft ODR orbit package installed to use the ODR orbit option in "make_raw.pl". This is not part of ROI_pac, so you have to install it separately if you want to use it. See the README. You can always use the "HDR" orbit option that uses the state vectors in the SARLEADER file. These may not be as accurate, but they are always available.
Where can I get PRC orbit data for ERS2?
You should contact the ESA Earth Observation (EO) Help Desk < eohelp@eo.esa.int > to ask for a password to their FTP site for the PRC orbits.
Too few points left after culling error
Hi, I'm processing data but I get this error before the process ends. do you have any suggestion?
+offset.pl Writing input_file: 960919-000928_ampcor.in +offset.pl /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_BIN/ampcor 960919-000928_ampcor.in rdf > 960919-000928_ampcor.out +make_offset.pl /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_BIN/fitoff 960919-000928_ampcor.off 960919-000928_cull.off 1.5 0.08 50 > fitoff_ampcor.out Too few points left after culling: 2 left +raw2ampintcor.pl make_offset.pl failed in raw2ampintcor.pl +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
can it be a problem with the orbit data?
There are a lot of reasons this step can fail. It is possible that bad orbit data could cause the baseline.pl script to not be able to estimate the gross offset. You should also apply the patch to baseline.pl from the Patches page. There are more hints on this web page: http://www.geo.cornell.edu/eas/PeoplePlaces/Faculty/matt/troubleshooting.html
Installing on a Mac
Hello im trying to install ROI_PAC on a MAC. It seemed to succeed but when i try to run the process_2pass.pl over the two TEST images i encounter the following Bus error:
+offset.pl /Users/Gerardo/Desktop/Insar/ROI_PAC_3_0/ROI_PAC/multibuild-090402-1132/installs/defaults/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out sh: line 1: 51214 Bus error /Users/Gerardo/Desktop/Insar/ROI_PAC_3_0/ROI_PAC/multibuild-090402-1132/installs/defaults/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out +offset.pl ampcor failed in offset.pl
some ideas? thanks in advance
I think I remember this kind of bus error with a version of the gfortran compiler. What compiler and version did you use?
Problem with test data
I'm starting to work on the test-dir of roi_pac and I'm experiencing some problems. One of them is that I have problems in conditioning raw data. This is what i get when i run the make_raw.pl
make_raw.pl PCR SARLEADER1993011018252739T1Of1 930110 +make_raw.pl Checking I/O Creating 930110.raw Creating 930110.raw.rsc +make_raw.pl General definitions +make_raw.pl Getting facility name +make_raw.pl Finding reference counter, pri and prf counter read: 900 swst offset read: 204 +make_raw.pl Reference counter = 900 +make_raw.pl Checking line number +make_raw.pl /new_parse 12060 200 4 1 IMAGERY1993011018252739T1Of3 tmp_IMAGERY.raw +make_raw.pl Reading the leader file +make_raw.pl /leader2rsc SARLEADER1993011018252739T1Of1 /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_SCR/format_leaderfile_CRDC-SARDPF tmp_IMAGERY.raw.rsc tmp_IMAGERY.raw has zero size
Maybe is a setting problem but also... I'm running ROI_pac on a linux terminal but the program reside on a solaris server. Can this be a problem? Thanks!!
I think you have a typo in your command it says "PCR" instead of "PRC" for the orbit type. It also looks like you did not define the INT_BIN environment variable.
Using state vector info for ENVISAT
Is there a way to use the state vector information in the raw ENVISAT data for determining the precise state vectors during the scene acquisition? With the make_raw_envi.pl program I get a bunch of blank fields for the state vectors in my hdr_data_points_??????.rsc file. I tried to write a hard-wired version, but without much luck.
No, the Envisat Level 0 (raw) data files only contain one state vector, which is not sufficient for processing. You must get the orbit information from either the ESA DORIS orbit files or the Delft ODR orbits.
Why was ROI_PAC only designed to process raw data?
Why was ROI_PAC only designed to process RAW images? Was this because ROI_PAC was designed to estimate the average Doppler value?
Yes, ROIpac was designed to process the two images at the average of the two Doppler centroids. It does the azimuth spectrum filtering (cutting out the part of the azimuth spectrum that does not overlap) in the "roi" program. It is possible to do the azimuth spectrum filtering in the interferogram formation, but this is not what "resamp_roi" does. The Delft DORIS software does the filtering in the interferogram stage, as it must because it starts with SLCs.
In addition, there is another significant difference between the way that ROIpac and other SAR processors use the Doppler centroid in the SLC formation. ROIpac is set up to process the SLC in the original geometry, but the ESA processor (and probably the Canadian Radarsat-1 processor) produce the SLC images in a deskewed geometry. The deskewing moves the data to adjust for the squint or angle between the radar LOS and perpendicular to the orbit track. Because the Radarsat-1 data has a large squint (typically about 3 degrees at middle latitudes), this is a large effect. This will make it extremely difficult if not impossible to combine ROIpac SLCs with the SLCs from the other processor.
It should be possible to make interferograms between two SLCs processed by the same system as long as the Doppler centroids are not too different. We did this with the Bam earthquake Envisat ASAR SLCs before we got the raw data. You should set the Doppler centroid to zero in the .slc.rsc file if you use ROIpac to process deskewed SLC data.
Processing Seasat data
I'm trying to process Seasat data by running it through roi (from roi.F) without using the perl scripts. Does it require the .rdf file and the .raw.rsc file?
The .raw.rsc files are not really necessary if you are running the roi program without the Perl scripts. The Perl scripts read the .rsc files to create the .rdf file, and the program only reads the .rdf file and the data files. To use the rest of the ROI_pac Perl scripts, you would want to create the .slc.rsc file for the output from roi.
I'm using the ERS1 rdf file as the template. In it, there are fields
i/q means (-) = 15.6555004 15.3079996 15.6555004 15.3079996 ! file 1 (i,q), file 2 (i,q) Flip i/q? (-) = n !
Seasat data is offset video so obviously does not have i/q. Does roi assume IQ? If so do I have to write a program that demodulates Seasat to baseband IQ? If not, how do I tell roi that my data is offset video? Or is there a separate routine that handles non complex data.
The roi program definitely processes offset-video data. I used it many times for SIR-C data that is offset video. You just need to put "o" (for offset video) in the "Flip i/q?" answer. It will do the decoding automatically.
Using ESA orbits for Envisat
I'm having difficulties using the DOR orbits for Envisat - make_raw_envi.pl appears to be able to use "DORIS" orbits (as orbit_type DOR) for Envisat data but process_2pass.pl does not seem to accept "DOR" as a valid type - what should I put as orbit_type in the .proc file?
When you use the DOR option in make_raw_envi.pl, the script copies the Envisat DORIS orbit data from ESA (either POR orbits from $POR_DIR or VOR orbits from $VOR_DIR) to a hdr_$date.rsc file. The rest of the processing should then be done with the $orbit_type set to HDR. This was a shortcut to avoid modifying the state_vector.pl script to read the Envisat DORIS orbit files.
YMAX bigger than FILE_LENGTH?
I'm trying to process a ALOS/PALSAR data. But, I cannot make interferogram yet. In the case of my data (*.slc.rsc), YMAX grows big than FILE_LENGTH. Probably, I can't make interferogram by this problem. Can you give me any advice?
//////My PALSAR Data////// Mode : FBS Level : 1.0 off-nadir angle : 34.3 Orbit Direction : Descending PRF : 2145.923000(Same PRF) SceneShift : -4 //////*.PRM////// num_rng_bins 11304 bytes_per_line 21100 good_bytes_per_line 21020 num_lines 35193 //////*.raw.rsc////// FILE_LENGTH 35193 XMIN 413 XMAX 21020 WIDTH 21100 YMIN 0 YMAX 35193 //////*.slc.rsc////// FILE_LENGTH 38680 XMIN 0 XMAX 10303 WIDTH 10303 YMIN 0 YMAX 40564
In ROI_pac it is normal for the YMAX of the SLC to be larger than the YMAX of the raw data. The difference is larger for PALSAR because it has a longer synthetic aperture. It is not clear why the YMAX of the SLC is larger than the FILE_LENGTH parameter. Are you using the ROI_pac v. 3.0 scripts?
How to skip multilooking ?
Does anyone know how to skip multilooking the interferogram?
To process the interferogram with no range looks (but still having azimuth looks determined by the pixel_ratio), you need to change three values to change the number of range looks:
Rlooks_int=1 Rlooks_unw=1 Rlooks_sim=1
How can I process a subset of my SAR image?
You can process a subset of the raw data file using a roi.proc file in the directory above the directories of the individual dates. This file is used to determine which part of the raw data to process for all of the dates. You can also put a file into the directories of the individual dates called $date.proc (whatever the name of your $date directory) with the same information. It should contain all the parameters you want to change in the processing of the raw data to SLC. For example:
before_z_ext = -1000 after_z_ext = -12000 near_rng_ext = -0 far_rng_ext = -3950
All of the "_ext" values are "extensions" from the area of the raw data, so negative extensions mean that the SLC will be smaller than the raw data. The default values are calculated in roi_prep.pl but the .proc file values will override the defaults.
Problems selecting an area of interest
I'm trying to select an area of interest from my SAR images and I modified file "roi.proc", like this:
before_z_ext = -13900 after_z_ext = -7076 near_rng_ext = -5900 far_rng_ext = -2250
then processing with command "process_2pass.pl int.proc" gave an error like this:
Creating 19960423.slc +roi.pl ROI_PAC_3_0/ROI_PAC/INT_BIN/roi 19960423_roi.in > 19960423_roi.out At line 812 of file ROI_PAC_3_0/ROI_PAC/roi/roi.F Fortran runtime error: RECL parameter is non-positive in OPEN statement +roi.pl roi failed in roi.pl +raw2ampintcor.pl roi.pl failed in raw2ampintcor.pl +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
The important thing to note is that the WIDTH in the .raw.rsc file is in bytes and there are two bytes for every data sample. The range extension values must be specified in samples, so you probably need to divide your near_rng_ext and far_rng_ext values by two. The width of most SAR images is around 6000 samples, so the near_rng_ext and far_rng_ext values you used add to much more than the full width. Also, for ERS data, there are usually an extra 412 bytes at the beginning of each raw data line XMIN 412 and this further reduces the width of the actual data.
Compiling problems
The roi binary (/usr/local/bin/roi 930110_roi.in > 930110_roi.out) is crashing (seg fault) on my Linux box while running the test data. How do I debug this? 930110_roi.out is an empty file...
As you may know, "segmentation violation" errors can be caused by a number of things. The first thing to check is whether the 930110_roi.in file has anything strange in it. Another thing to check is the build and link to the FFTW libraries. It is strongly recommended that you use the contrib/install-fftw.sh script to build FFTW with the required single-precision code and use that. Other FFTW builds are not likely to work. If the FFTW build is bad or incompatible, then all of the programs that use them will fail.
930110_roi.in seems OK. The FFTW library "make check" worked OK. Here are the symbols I defined: 'FFTW_LIB_DIR=/usr/lib 'FFTW_INC_DIR=/usr/include 'SAR_ODR_DIR=/opt/ROI_PAC_3_0/Delft 'SAR_PRC_DIR=/opt/TEST_DIR/PRC 'FFTW_LIB=/usr/lib INT_SCR=/opt/ROI_PAC_3_0/ROI_PAC/INT_SCR I also added /opt/ROI_PAC_3_0/ROI_PAC/INT_SCR:/opt/ROI_PAC_3_0/ROI_PAC/fip to my path. Is there anything missing? Is there a way to get a core file or something?
Core file generation is controlled by your shell. Often the "coredumpsize" is set to zero in the shell, which causes no core files to be created. Under Linux csh-type shells, you can use limit core 10m to set the limit to 10 MB.
I ran roi with ulimit -c 65000 and I got a big core file, but gdb says that the /opt/ROI_PAC_3_0/TEST_DIR/930110/core file created isn't a recognized core file. What am I missing? Is there another way to see why it's crashing? Are there metrics somewhere that say what the memory/paging/etc limits are?
You probably need to compile the code with the debugging symbols to use gdb effectively. You can build ROI_pac with the debugging flag -g by using the gfortran-g build of contrib/multibuild.sh. Another debugging tool in Linux is strace which will print information about all the system calls made by the program.
Processing TerraSAR-X SLCs?
I'm trying to process TerraSAR-X dual-pol SLCs. To use ROI_PAC I need to manually create parameter files. Has anyone done this? If so, what files need to be created and what variables do I need from the XML file? I already wrote software to strip the headers in the COSAR format they come in. If it's not obvious, I haven't used ROI_PAC before (just Vexcel's Phase).
I have not done this myself, but I have seen another person's TerraSAR-X interferogram. If you have not used ROI_pac before, I would recommend processing the sample dataset and examining the .slc.rsc files that contain the metadata about the .slc images.
Using make_raw.pl with CEOS data from EODC and other ground stations?
I'm having a problem using make_raw.pl with some raw ERS data. I think it may come down to CEOS, "the Standard that isn't"...!
My raw ERS data was downloaded in the UK. However, the CEOS leader file doesn't say "UK-PAF" as I'd expected, but "EODC FARNBOROUGH". I suspected that as this data was all downloaded at a DRA/DERA/QinetiQ groundstation the flavour of CEOS was going to be just like "UK-PAF". I therefore modified make_raw.pl by adding the following line:
elsif ($facility eq "EODC") { $facility = "UK-PAF";}
However, this merely produced a load of:
Keyword FIRST_FRAME_SCENE_CENTER_LINE doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_HOUR_OF_DAY doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_MN_OF_HOUR doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_S_OF_MN doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_MS_OF_S doesn't exist in tmp_IMAGERY.raw.rsc, returning 0
Followed by:
No good range counter found using reference counter = 4114
I also tried to modify make_raw.pl several times to trick it into thinking "EODC" was each of the other PAF. For example:
elsif ($facility eq "EODC") { $facility = "D-PAF";}
However, the result was the same. This makes me think "EODC FARNBOROUGH" is another unique CEOS flavour and the Imagery and Leader data files are therefore being read incorrectly. How does one begin modifying make_raw.pl to ingest CEOS data from other ground stations? I suspect the first step is to find the correct number of bytes in the Imagery and Leader files for the various make_raw.pl parameters... but I'd need help figuring this out...
The first thing to try is just specifying the facility on the make_raw.pl command line. It is an optional fourth parameter. This will allow you to try the different facility types already supported without changing the Perl script. It sounds like your modifications were not working correctly.
If you are sure that none of the existing facilities will work for your data, then you need to find a reference document for the facility that processed your data. The help desk of that facility may be able to help.
PALSAR pairs which won't register?
- I'm trying to do some InSAR using ROI_PAC with several PALSAR pairs. The occasional pair works well, but in several cases I just cannot get the two SLC to register. I keep getting the classic error (already mentioned above):
Too few points left after culling, 2 left
- I should mention that in all cases the SLCs are each made from two adjacent scenes. I used the latest make_raw_alos.pl to pre-process these, which worked without any errors and filesizes are as expected. All pairs cover a coastal area, but about 2/3 of the area in the SLCs are solid ground, as is the centre of the scene. There is certainly more than enough solid ground for good registration. Here are some observations from one of the pairs...
- I've checked the PRF (~2100) and they are very close to each other.
The version 3.0.1 should handle PRF differences much better than previous versions. The new version uses the difference between the PRF values to calculate a scale factor for the azimuth direction and uses this in the matching.
- I also checked the DOPPLER_RANGE0 value in the both the *.raw.rsc and the values are within the correct 0.5 and -0.5 range.
- I tried pixel_ratio=2 in the *.proc file, which improved things slightly. I got 198 points initially, which were then culled to just 2 again!
If the gross matching was good and resulted in a good number of points, then the initial offsets from the orbits must be OK.
The obvious thing that cried out to me was a large azimuth offset caused by timing errors (as in Eric Fielding's example http://www.roipac.org/AlosExample). I took a closer look at the SLCs and found a large (excessive?) azimuth offset of ~3170 (even more than Eric's example and maybe ~1.5 second timing error?). Therefore I used y_start=3170 in the *.proc file. However, now I don't even get the 198 initial offset points, again! I thought I might have got the sign wrong, so tried y_start=-3170, but there was no change in the result. The range offsets are negligible, but I tried adding x_start=0.01 just in case, but to no avail.
If you specify y_start, then you should also specify the x_start. Normally both are integers.
I also tried modifying the offsets using the instructions here (also referenced above): http://www.geo.cornell.edu/eas/PeoplePlaces/Faculty/matt/troubleshooting.html No matter what sign I use this also fails.
- The SLCs looks sensible and well focused with no obvious problems (at least that I can see). There is some Radio frequency interference (RFI), but there seems to be plenty enough non-RFI areas to allow a good registration. I haven't seen anyone else mention RFI in PALSAR though...?
Radio-frequency interference is a big problem for PALSAR data in some areas, depending on the local use of L-band radio frequencies.
- Does anyone have any other suggestions about what might be going wrong and how to fix it? I can't help thinking this is a PALSAR-specific issue related to timing...
Running "PlotOffset.pl" on the *ampcor.off file should help diagnose why the fine culling is failing. You will need to install the "xmgrace" program if you don't already have it.
Simulated SAR image (from DEM) contains stripes
I've used ROI_PAC for a while and have had few errors registering with the DEM besides those caused by human error. I've now started to get the classic error again:
synth_offset.pl Culling points dem2diff.pl synth_offset.pl failed in dem2diff.pl process_2pass.pl dem2diff.pl failed in process_2pass.pl
When this has happened before I instinctively think it is something wrong with my DEM. I then go and check the byte order, data type (short integer) etc. and usually discover I've made an error. When I fix the error things run smoothly. However, this time the DEM appears to check out OK (although human error may still play its part!). I'm using Linux and the byte order is correct for this. The data type is signed 16-bit short integer. I've tried different grid spacing (making it both larger and smaller). I've also tried using X and Y grid spacings that are the same and others that differ. The area has plenty of relief and therefore enough texture in the simulated SAR to make a good registration possible. The next step in my "investigation" was to check out the simulated SAR image itself (SIM_raw.hgt). This is where I think I've found something unusual. It has lots and lots of blank stripes 1 pixel deep running left-right across it (see below). I've seen stripes like this before, usually in areas of moderate/high relief where the pixel spacing is irregular when projected into SAR coordinates. However, I've never seen THIS many! I suspect they are the cause of the failed DEM registration? Would anyone like to confirm if this is indeed likely to cause a registration to fail, and/or suggest what might be causing the stripes? Perhaps there is something else wrong with my DEM preparation that I might have missed??
The SIM_raw.hgt file almost always has some voids in it, with the pattern depending on how the DEM spacing is mapped into the SAR image coordinates. If the DEM has a coarser spacing than the SAR data, then the voids can be a majority of the pixels. Normally, the "Aik_resample" program that is run after IntSim interpolates over these voids to produce a SIM_4rlks.hgt (or similar) file that is used in the rest of the processing.
You should compare the SIM_4lks.hgt file to the date1-date2_4rlks.cor file to see if they look similar because those are the files that are matched by "synth_offset.pl"
Can Sky Telemetry Format be processed?
How can Sky Telemetry Format (STF) Level 0 raw data (rather than CEOS) be ingested with make_raw.pl or other scripts?
The Sky Telemetry Format (STF) data from ASF cannot be ingested with the programs released with ROI_pac v. 3.0. The data format is completely different, so it requires a different program to read the STF level 0 data. We hope to include the STF data reading program and associated scripts with the 3.0.1 release.
How to convert unwrapped phase to range change?
A simple, yet fundamental question... how do you convert unwrapped phase in the file geo-DATE1-DATE2.unw into units of displacement (e.g. cm) for any given sensor?
The unwrapped phase can be converted to range change by multiplying the phase (in radians) by the radar wavelength/4*pi with the length units of the wavelength.
How can I geocode the wrapped interferogram with geomap.trans?
If you already have the geomap(_4rlks).trans file from a successful run of process_2pass.pl, then you can geocode the wrapped interferogram (.int) file.
Unfortunately, the geocode.pl script only knows how to geocode the unwrapped interferograms. To geocode the wrapped interferogram, you need to edit the rect_lookup.in file to change the input file name to your date1-date2(_4rlks).int file (must have the same number of looks as the geomap.trans file) and the output file name to whatever you want to call the output. You also need to change the "file type" to CPX and the "Interpolation Method" to Sinc. Then run the rect_lookup" program with the edited input file rect_lookup rect_lookup.in.
-
Question about ROI_PAC test run
- I have been trying to run the test data using ROI_PAC. i modified the SAR_CONFIG file to set the different variables. make_raw.pl ran perfectly for both the images. The last message i saw was
+offset.pl /export/software/roi_pac/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out
- nothing happened for more than an hour. Is it supposed to take that long? I noticed the file size was 0 bytes . I accidentally suspended the process when i tried to copy this message and will run it again, but would like to know if i should just let it run for as long as it takes or is something wrong at this step.
The ampcor program can take a while to run, but it should finish in less than 10 minutes on a reasonably fast computer.
Radiometric correction/calibration on the *.amp files?
Does ROI_PAC perform radiometric corrections/calibration on the *.amp files based on ground slope/aspect? I.e., is there any correction on the amplitude values for terrain-induced variations of the local illuminated area?
No, ROI_pac does not do any radiometric corrections or calibrations. All of the SAR amplitude images are completely uncalibrated. ROI_pac is only designed to accurately process the interferometric phase.
How can I use a DEM in UTM projection?
- I've been trying to use a DEM in UTM projection. It can't get it to work and suspect I've got the details wrong in the *.dem.rsc parameter file. I can't find any definitive information on the web about making a *.dem.rsc for UTM, although Eric Fielding's UNAVCO course notes are a big help. Can anyone please post a full example UTM *.dem.rsc (including pixel spacing, projection, zone, datum etc.) as a starting point...? One thing I certainly don't understand is the zone variable. For example, does one use the full zone code (e.g. 34U)? Many thanks.
ROI_pac does not require the full zone code with the letter specifying the latitude band, just the zone number appended to "UTM". 28n057e-31n060e.srtm3-utm40-160m.dem.rsc is an example of a .dem.rsc file for UTM zone 40. Note that the Y_STEP is negative if your DEM goes from north to south in its scan lines, for UTM or LATLON projections.
Can't visualize date.slc file
I am processing PALSAR data. I get to the end of the process but I can't visualize the both the date.slc files. I can see the date_16rlks.slc. MDX returns this message:
Cannot open the filename: date.slc STOP set number less than or equal to zero statement executed
- I can't figure out the problem. Any idea?
It sounds like your MDX program was not compiled with the large file flags, so it does not know how to open a >2 GB SLC file.
Can ROI-PAC work with different client processing at the same time?
- I am working on a sun server (sun solaris) and three terminal (running linux red hat). It is possible to run different processes at the same time on the different terminals? I am experiencing some strange and random errors (the same command sometimes works and sometimes not, or I have to reboot the terminal to make it work) and I was wondering if it can be related to the fact that the terminals share the scripts on the server. It would be better to compile a copy of the program on each terminal and share just the data?
There should be no problem with running ROI_pac on different terminals at the same time, as long as you are processing different data. You can't process the same scene as part of two different pairs at the same time (unless you make a separate copy of the raw and slc directory for the date) because ROI_pac focuses the SLC optimized for each pair.
