issues reading external DEM (ASTER)

dchow...@appliedgeosolutions.com

unread,

Mar 17, 2015, 11:26:38 AM3/17/15

to adore...@googlegroups.com

Hi there,

I seem to be having issues reading my DEM correctly into adore/doris. My study region is in Sweden (+60N) so I'm using an ASTER DEM which I downloaded as a .tif tile. I then converted it to ESRI bil format using:

>>ADORE: dem import path/to/file

>>ADORE: dem extent

DEM extent w/e/s/n: 17.000139/21.003339/66.996661/70.999861

which seems to be the same as when I run gdalinfo on the dem file:

Driver: EHdr/ESRI .hdr Labelled

Files: ASTR_DEM2.bil

ASTR_DEM2.bil.aux.xml

ASTR_DEM2.hdr

ASTR_DEM2.prj

Size is 14400, 14400

Coordinate System is:

GEOGCS["GCS_WGS_1984",

DATUM["WGS_1984",

SPHEROID["WGS_84",6378137,298.257223563]],

PRIMEM["Greenwich",0],

UNIT["Degree",0.017453292519943295]]

Origin = (17.000000000000011,70.999999999999986)

Pixel Size = (0.000277777777778,-0.000277777777778)

Metadata:

AREA_OR_POINT=Area

Corner Coordinates:

Upper Left ( 17.0000000, 71.0000000) ( 17d 0' 0.00"E, 71d 0' 0.00"N)

Lower Left ( 17.0000000, 67.0000000) ( 17d 0' 0.00"E, 67d 0' 0.00"N)

Upper Right ( 21.0000000, 71.0000000) ( 21d 0' 0.00"E, 71d 0' 0.00"N)

Lower Right ( 21.0000000, 67.0000000) ( 21d 0' 0.00"E, 67d 0' 0.00"N)

Center ( 19.0000000, 69.0000000) ( 19d 0' 0.00"E, 69d 0' 0.00"N)

Band 1 Block=14400x1 Type=Float32, ColorInterp=Undefined

Checking master and slave images for extent:

>>ADORE: s result m_readfiles

*_Start_readfiles:

*******************************************************************

Volume file: product.xml

Volume_ID: PDS_03963680

Volume_identifier: RN-RP-51-2713, Issue 1/11

Volume_set_identifier: DUMMY

(Check)Number of records in ref. file: 5517

SAR_PROCESSOR: RN CAPPS SAR 1.1

SWATH: Q25

PASS: Ascending

IMAGING_MODE: FQ25 HH VV HV VH

RADAR_FREQUENCY (Hz): 5404999242.769673

Product type specifier: RADARSAT-2

Logical volume generating facility: GSS

Logical volume creation date: 2014-08-01T16:25:54.000000Z

Location and date/time of product creation: 2014-07-02T16:23:01.312622Z

Scene identification: Orbit: 34187 2014-07-02T16:23:01.702375Z

Scene location: lat: 68.4492 lon: 19.1400

Leader file: product.xml

Sensor platform mission identifer: RADARSAT-2

Scene_centre_latitude: 6.844920000000000e+01

Scene_centre_longitude: 1.914000000000000e+01

Scene_centre_heading: Null

Radar_wavelength (m): 0.055465772433

First_pixel_azimuth_time (UTC): 02-Jul-2014 16:23:01.702375

Pulse_Repetition_Frequency (computed, Hz): 2.598877441406250e+03

Total_azimuth_band_width (Hz): 9.000000000000000e+02

Weighting_azimuth: KAISER

Xtrack_f_DC_constant (Hz, early edge): 1.868190405359000e+02

Xtrack_f_DC_linear (Hz/s, early edge): 1.305914242445834e+05

Xtrack_f_DC_quadratic (Hz/s/s, early edge): -3.330788679500000e+07

Range_time_to_first_pixel (2way) (ms): 7.052600822266183

Range_sampling_rate (computed, MHz): 31.669922

Total_range_band_width (MHz): 30.02442

Weighting_range: KAISER

*******************************************************************

Datafile: imagery_HH.tif

Dataformat: GeoTIFF

Number_of_lines_original: 4796

Number_of_pixels_original: 4040

*******************************************************************

* End_readfiles:_NORMAL

>>ADORE: s result s_readfiles

*_Start_readfiles:

*******************************************************************

Volume file: product.xml

Volume_ID: PDS_03829590

Volume_identifier: RN-RP-51-2713, Issue 1/11

Volume_set_identifier: DUMMY

(Check)Number of records in ref. file: 5517

SAR_PROCESSOR: RN CAPPS SAR 1.1

SWATH: Q25

PASS: Ascending

IMAGING_MODE: FQ25 HH VV HV VH

RADAR_FREQUENCY (Hz): 5404999242.769673

Product type specifier: RADARSAT-2

Logical volume generating facility: GSS

Logical volume creation date: 2014-07-27T19:51:18.000000Z

Location and date/time of product creation: 2014-07-26T16:23:01.089416Z

Scene identification: Orbit: 34530 2014-07-26T16:23:01.449925Z

Scene location: lat: 68.4477 lon: 19.1412

Leader file: product.xml

Sensor platform mission identifer: RADARSAT-2

Scene_centre_latitude: 6.844770000000000e+01

Scene_centre_longitude: 1.914120000000000e+01

Scene_centre_heading: Null

Radar_wavelength (m): 0.055465772433

First_pixel_azimuth_time (UTC): 26-Jul-2014 16:23:01.449925

Pulse_Repetition_Frequency (computed, Hz): 2.598877441406250e+03

Total_azimuth_band_width (Hz): 9.000000000000000e+02

Weighting_azimuth: KAISER

Xtrack_f_DC_constant (Hz, early edge): 1.456710540103000e+02

Xtrack_f_DC_linear (Hz/s, early edge): 7.327544442676030e+04

Xtrack_f_DC_quadratic (Hz/s/s, early edge): -1.909851531800000e+07

Range_time_to_first_pixel (2way) (ms): 7.052600822266183

Range_sampling_rate (computed, MHz): 31.669922

Total_range_band_width (MHz): 30.02442

Weighting_range: KAISER

*******************************************************************

Datafile: imagery_HH.tif

Dataformat: GeoTIFF

Number_of_lines_original: 4802

Number_of_pixels_original: 4040

*******************************************************************

* End_readfiles:_NORMAL

ADORE: s sam_in

sam_in_delta=0.000278 0.000278

sam_in_dem=ASTR_DEM2.bil

sam_in_format=r4

sam_in_nodata=-9999

sam_in_size=14400 14400

sam_in_ul=70.999861 17.000139

I run m_readfiles, s_readfiles, s_crop, m_crop successfully/without any warnings. However when I run m_simamp I get the following warnings:

>>ADORE: m_simamp

PROGRESS: Start SIMULATE AMPLITUDE.

INFO : DEM input: w/e/s/n: 17.0001/21.0031/66.9969/70.9999

INFO : DEM input required: w/e/s/n: 18.6333/19.661/68.1598/68.6291

INFO : DEM input window (l0,lN,p0,pN): 8527 10217 5874 9572

INFO : For master window (l0,lN,p0,pN): 1 4796 1 4040

INFO : DEM output total pixels: 3699

INFO : DEM output total lines : 1691

INFO : Radar coding of DEM in: 1 buffers of 1691 lines and 0 extra buffer of 0 lines.

PROGRESS: SAM: Buffer# [l0:lN, p0:pN]: 1 [8527: 10217, 5874: 9572]

PROGRESS: SAM: Reading crop of DEM for buffer: 1

INFO : Read crop of input DEM: format: REAL4.

PROGRESS: Converting DEM to radar system for this buffer.

INFO : Number of points in DEM: 6255009

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 0 (0%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 100 (6%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 200 (12%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 300 (18%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 400 (24%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 500 (30%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 600 (35%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 700 (41%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 800 (47%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 900 (53%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1000 (59%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1100 (65%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1200 (71%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1300 (77%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1400 (83%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1500 (89%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 1600 (95%)

PROGRESS: SAM: Writing radar coded DEM and the incidence angle (theta) to files, buffer: 1 of 1

PROGRESS: SAM: Start interpolation...

INFO : Master azimuth spacing: 2.52865

INFO : Master range spacing: 6.78151

INFO : Range-azimuth spacing ratio: 2.68187

INFO : Interpolation in: 1 buffers of 2579 lines and 1 extra buffer of 2217 lines.

PROGRESS: SAM: Interpolation buffer: 1of2 [l0:lN, p0:pN]: [1: 2579, 1: 4040]

PROGRESS: SAM: Reading input for interpolation buffer: 1of2

INFO : griddataLinear interpolation.

PROGRESS: SAM: Writing radar coded SIM_AMPLITUDE to file, buffer#: 1 of 2

PROGRESS: SAM: Interpolation buffer: 2of2 [l0:lN, p0:pN]: [2580: 4796, 1: 4040]

WARNING : (getcorners) indexphi0DEM: -1

WARNING : DEM does not cover entire interferogram.

WARNING : input DEM should be extended to the North.

WARNING : (getcorners) indexlambda0DEM: -1

WARNING : DEM does not cover entire interferogram.

WARNING : input DEM should be extended to the West.

PROGRESS: SAM: Reading input for interpolation buffer: 2of2

INFO : griddataLinear interpolation.

PROGRESS: SAM: Writing radar coded SIM_AMPLITUDE to file, buffer#: 2 of 2

INFO : Closing output files

INFO : Min. value of input DEM covering sim. amplitude (master): 0

INFO : Max. value of input DEM covering sim. amplitude (master): 1792

PROGRESS: Finished SIMULATE AMPLITUDE.

INFO : Current time: Tue Mar 17 10:21:04 2015

total cpu: 1 min 12.21 sec

INFO :

INFO : master: latest known processing stage: simamplitude

PROGRESS: calling preview for simulated amplitude

INFO : Reading parameters from: ./20140726.res

INFO : sec of day of first azimuth line: 58981.4

INFO : Checking file: ./20140726.res

INFO : Yeah, Radarsat-2!

INFO : Range to pixel 1 = 1057158.268 m

INFO : Range to pixel 4040 = 1076275.172 m

INFO : Doppler centroid frequency: at pixel 1 (early edge): 145.671 Hz

INFO : Doppler centroid frequency: at pixel 4040 (far edge): 154.706 Hz

INFO : Doppler centroid frequency: at pixel 60754.136 (maximum): 215.955 Hz

INFO : sensor: 70

[orbit.cc] orbvector_type: 30 vs velo prm fixed: 31

INFO : 5 datapoints (t,x,y,z) read from: "./20140726.res"

INFO : Setting default orbit interpolation method.

INFO : Computing coefficients for orbit polyfit degree: 3

INFO : Max. approximation error at datapoints (x,y,or z?): 1.85193e-06m

INFO : Max. approximation error at datapoints (x,y,or z?): 4.15603e-07m

INFO : Max. approximation error at datapoints (x,y,or z?): 1.08946e-05m

PROGRESS: Orbit: interpolation coefficients computed.

INFO : Max. error bperp modeling at 3D datapoints: 1.58049e-05m

INFO : The baseline parameters for (l,p,h) = 2399, 2021, 0

INFO : Bpar, Bperp: 5.03735 14.1239

INFO : Height ambiguity: -1461.46

INFO : Look angle (deg): 38.2818

INFO : The baseline parameters for (l,p,h) = 2399, 2021, 1000

INFO : Bpar, Bperp: 5.05589 14.1188

INFO : Height ambiguity: -1464.24

INFO : Look angle (deg): 38.3587

INFO : No tiepoint given.

INFO :

INFO : slave: latest known processing stage: crop

INFO : Checking file: ./20140726.crop

INFO : Current time: Tue Mar 17 10:21:04 2015

total cpu: 1 min 12.23 sec

Processing results are in parameter file:

./20140702.res

...tip: The "run" script can be used to generate template input files.

--- WARNING SUMMARY ---

There were 6 messages:

1: (getcorners) indexphi0DEM: -1

2: DEM does not cover entire interferogram.

3: input DEM should be extended to the North.

4: (getcorners) indexlambda0DEM: -1

5: DEM does not cover entire interferogram.

6: input DEM should be extended to the West.

Normal termination.

Thank you for using Doris.

m_simamp: SUCCESS

The DEM appears to be much larger than the required DEM extent yet I get the above warnings. Could anyone please help me with this?

Best,

Diya

Batuhan Osmanoglu

unread,

Mar 18, 2015, 3:08:18 PM3/18/15

to dchow...@appliedgeosolutions.com, adore...@googlegroups.com

Hello Diya,

DORIS is reporting that the SAR data is slightly to the west:

INFO : DEM input: w/e/s/n: 17.0001/21.0031/66.9969/70.9999

INFO : DEM input required: w/e/s/n: 18.6333/19.661/68.1598/68.6291

Can you not extend the DEM? I recently fixed the ASTER DEM download code, so you can use the construct_aster_dem.sh to download a DORIS friendly aster DEM giving the coordinates mentioned above. Let me know if id does not work. I didn't tie it with "dem make" yet, but that is a possibility for future.

DORIS requires a bit larger DEM so that when it is trying to radarcode the DEM it does not have nan values at the edges. I routinely put a 20% buffer around what I normally expect, and sometimes will even put a 50% buffer to make sure the data falls on the DEM.

Best,

batu

--

Batuhan Osmanoglu, Ph.D.
Partner

BOS Technologies, LLC

http://bostechnologies.com

--
You received this message because you are subscribed to the Google Groups "ADORE-DORIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adore-doris...@googlegroups.com.
To post to this group, send email to adore...@googlegroups.com.
Visit this group at http://groups.google.com/group/adore-doris.
For more options, visit https://groups.google.com/d/optout.

Diya Chowdhury

unread,

Mar 19, 2015, 12:40:35 PM3/19/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for your reply. I guess I am confused about the coordinate system. The entire study region is East of the Prime Meridian so I thought the above indicates that it requires a DEM that extends from 18E to 19E, which falls within the given DEM extent of 17E and 21E?

Is there a way I can grab the updated code? It appears when I use the construct_aster_dem.sh script in my current adore/scr folder it is unable to login to : www.gdem.aster.ersdac.or.jp which doesn't seem to be a valid link.

When I check for updates I get:

!ADORE: check updates

updates:

grep: updates: No such file or directory

(standard_in) 2: syntax error

grep: Start_process_control: invalid context length argument

Thanks!

-Diya

Batuhan Osmanoglu

unread,

Mar 24, 2015, 11:53:56 PM3/24/15

to Diya Chowdhury, adore...@googlegroups.com

Hello Diya,

Seems like something changed on the JAXA website and was causing the problem. It should work now, The new code is in the svn, same place as before.

I used your DEM extent (DEM extent w/e/s/n: 18.000000/21.002678/67.998122/70.000000) to test, and the generated DEM is here:

https://dl.dropboxusercontent.com/u/18918772/DEM.tar.bz2

After unzipping it you can use "dem load DEM.bil" to load in Adore. To verify, please check:

dem extent

and

dem view

commands.

Oh, and I added a new stitch method (-s 4) which outputs something that ADORE can load easily.

best,

batu.

On Tue, Mar 24, 2015 at 11:56 AM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Okay sure, thanks!

-Diya

On Fri, Mar 20, 2015 at 5:34 PM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:
Hi Diya,

Let me check, may be there is a bug in the code.

All the best,
Batu.

On Mar 20, 2015 4:55 PM, "Diya Chowdhury" <dchow...@appliedgeosolutions.com> wrote:
Hi Batu,

Heh sure. So I downloaded the code from the link you sent me and I'm having trouble with it.

./construct_aster_dem.sh -n DEM -u XXXX -p YYYY -c climate -f /home/dchowdhury/RSAT/ -s 2 18.6333 19.661 68.1598 68.6291

Category set to Climate
Coordinates(WESN)= 18 20 68 69

--------------------------------------------------
Downloading gdem and merging the tiles ...
--------------------------------------------------

ASTGTM2_N68E018_dem.tif
Downloading ASTGTM2_N68E018.zip
Logging in user: dchowdhury
2015-03-20 15:53:18 URL:http://gdem.ersdac.jspacesystems.or.jp/index.jsp [7346/7346] -> "/tmp/loginFile" [1]
Downloading Tile: 43_014
2015-03-20 15:53:19 URL:http://gdem.ersdac.jspacesystems.or.jp/gdServletAsyn/SetTileList?time=1426881198667 [60/60] -> "/tmp/selectFile" [1]
2015-03-20 15:53:20 URL:http://gdem.ersdac.jspacesystems.or.jp/tile_list.jsp [4915/4915] -> "/tmp/listFile" [1]
2015-03-20 15:53:21 URL:http://gdem.ersdac.jspacesystems.or.jp/agreement.jsp [3824/3824] -> "/tmp/categoryFile" [1]
2015-03-20 15:53:23 URL:http://gdem.ersdac.jspacesystems.or.jp/download.jsp [6137/6137] -> "/tmp/downloadsFile" [1]
http://113.35.103.196/_gd_download_file_name ASTGTM2_N68E018.zip
--2015-03-20 15:53:23-- http://astgtm2_n68e018.zip/
Resolving astgtm2_n68e018.zip (astgtm2_n68e018.zip)... failed: Name or service not known.
wget: unable to resolve host address `astgtm2_n68e018.zip'
--2015-03-20 15:53:23-- http://113.35.103.196/gdServlet/Download
Connecting to 113.35.103.196:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `/tmp/_gd_download_file_name'

[ <=> ] 0 --.-K/s in 0s

2015-03-20 15:53:24 (0.00 B/s) - `/tmp/_gd_download_file_name' saved [0/0]

Archive: /tmp/_gd_download_file_name
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/_gd_download_file_name or
/tmp/_gd_download_file_name.zip, and cannot find /tmp/_gd_download_file_name.ZIP, period.
Error downloading tile. Non-existing tile. Might be all water.
Skipping ASTGTM2_N68E018
ASTGTM2_N68E019_dem.tif
Downloading ASTGTM2_N68E019.zip
Downloading Tile: 44_014
2015-03-20 15:53:25 URL:http://gdem.ersdac.jspacesystems.or.jp/gdServletAsyn/SetTileList?time=1426881204584 [60/60] -> "/tmp/selectFile" [1]
2015-03-20 15:53:26 URL:http://gdem.ersdac.jspacesystems.or.jp/tile_list.jsp [4915/4915] -> "/tmp/listFile" [1]
2015-03-20 15:53:27 URL:http://gdem.ersdac.jspacesystems.or.jp/agreement.jsp [3824/3824] -> "/tmp/categoryFile" [1]
2015-03-20 15:53:29 URL:http://gdem.ersdac.jspacesystems.or.jp/download.jsp [6137/6137] -> "/tmp/downloadsFile" [1]
http://113.35.103.196/_gd_download_file_name ASTGTM2_N68E019.zip
--2015-03-20 15:53:29-- http://astgtm2_n68e019.zip/
Resolving astgtm2_n68e019.zip (astgtm2_n68e019.zip)... failed: Name or service not known.
wget: unable to resolve host address `astgtm2_n68e019.zip'
--2015-03-20 15:53:29-- http://113.35.103.196/gdServlet/Download
Connecting to 113.35.103.196:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `/tmp/_gd_download_file_name'

[ <=> ] 0 --.-K/s in 0s

2015-03-20 15:53:30 (0.00 B/s) - `/tmp/_gd_download_file_name' saved [0/0]

Archive: /tmp/_gd_download_file_name
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/_gd_download_file_name or
/tmp/_gd_download_file_name.zip, and cannot find /tmp/_gd_download_file_name.ZIP, period.
Error downloading tile. Non-existing tile. Might be all water.
Skipping ASTGTM2_N68E019

...and so on for all the tiles. Any idea what might be the issue?

Thanks,
Diya

On Thu, Mar 19, 2015 at 8:03 PM, Batuhan Osmanoglu <ba...@bostechnologies.com> wrote:
Hi Diya,

I normally trust Doris more then my math ;) so if Doris says it needs to be expanded I expand it ;)

The updated construct_aster_dem.sh is online:
https://code.google.com/p/adore-doris/source/browse/trunk/scr/construct_aster_dem.sh

You should be able to get it if you run:
ADORE: check updates

best,
batu.

Diya Chowdhury

unread,

Mar 25, 2015, 1:16:54 PM3/25/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks again for all your help so far. I used the 'new and improved' dem and am back to square one with the doris error when I run m_simamp:

PROGRESS: Start SIMULATE AMPLITUDE.

INFO : DEM input: w/e/s/n: 18/21.0024/67.9984/70

INFO : DEM input required: w/e/s/n: 18.6333/19.661/68.1598/68.6291

INFO : DEM input window (l0,lN,p0,pN): 4931 6620 2278 5975

INFO : For master window (l0,lN,p0,pN): 1 4796 1 4040

INFO : DEM output total pixels: 3698

INFO : DEM output total lines : 1690

INFO : Radar coding of DEM in: 1 buffers of 1690 lines and 0 extra buffer of 0 lines.

INFO : Found completed sam_m_theta.temp!

INFO : Using the existing file sam*.temp from the Radar coding step...

INFO : Min. value of input DEM covering sim. amplitude (master): 100000

INFO : Max. value of input DEM covering sim. amplitude (master): -100000

PROGRESS: Finished SIMULATE AMPLITUDE.

INFO : Current time: Wed Mar 25 12:09:13 2015

total cpu: 0 min 30.58 sec

INFO : Current time: Wed Mar 25 12:09:13 2015

total cpu: 0 min 30.59 sec

Processing results are in parameter file:

./20140702.res

...tip: Check out "http://doris.tudelft.nl/dig/"

--- WARNING SUMMARY ---

There were 6 messages:

1: (getcorners) indexphi0DEM: -1

2: DEM does not cover entire interferogram.

3: input DEM should be extended to the North.

4: (getcorners) indexlambda0DEM: -1

5: DEM does not cover entire interferogram.

6: input DEM should be extended to the West.

Normal termination.

Thank you for using Doris.

m_simamp: SUCCESS

Any thoughts?

-Diya

Batuhan Osmanoglu

unread,

Mar 25, 2015, 5:02:40 PM3/25/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Let's give it another degree in north and west... Hopefully that will do it. So please generate a new DEM with larger area and try again.

Best,

batu.

Diya Chowdhury

unread,

Mar 27, 2015, 11:49:28 AM3/27/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

I extended it a degree and no change:

INFO : DEM input: w/e/s/n: 17/21.0032/67.9976/71

INFO : DEM input required: w/e/s/n: 18.6333/19.661/68.1598/68.6291

INFO : DEM input window (l0,lN,p0,pN): 8528 10217 5875 9573

INFO : For master window (l0,lN,p0,pN): 1 4796 1 4040

INFO : DEM output total pixels: 3699

INFO : Current time: Fri Mar 27 10:42:54 2015

total cpu: 0 min 30.99 sec

INFO : Current time: Fri Mar 27 10:42:54 2015

total cpu: 0 min 31.01 sec

Processing results are in parameter file:

./20140702.res

...When we ask advice, we are usually looking for an accomplice.

--- WARNING SUMMARY ---

There were 6 messages:

1: (getcorners) indexphi0DEM: -1

2: DEM does not cover entire interferogram.

3: input DEM should be extended to the North.

4: (getcorners) indexlambda0DEM: -1

5: DEM does not cover entire interferogram.

6: input DEM should be extended to the West.

Normal termination.

Thank you for using Doris.

m_simamp: SUCCESS

Sorry to badger you but I can't imagine what the problem is since I've tried feeding it DEM's extended by upto 3 degrees to the W and N and still got that error.

Thanks,

-Diya

Batuhan Osmanoglu

unread,

Mar 27, 2015, 1:08:01 PM3/27/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Can you let me know what data this is and if I can get a copy? This way I can just take a look.

something weird may be going on.

Best,
Batu.

Batuhan Osmanoglu

unread,

Apr 3, 2015, 4:58:11 PM4/3/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Please do a "check updates". The latest version is 0.1.470... It is possible stuff changed from 0.1.355...

If I remember correctly check setup only gives good results on 32-bit OS with Intel CPU. If you are using 64-bit OS or AMD, it will indicate failure because the checksums are different. But that does not necessarily mean all is bad.

You can display the interferogram and see if it is looking OK.

best,

batu.

On Fri, Apr 3, 2015 at 3:57 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

Still no dice on the Radarsat2 processing with DEM. Previously we had installed adore-doris version(0.1+r238-0ubuntu0ppa1) and now we just tried installing version(0.1.355-0ubuntu0ppa3) and no change.

Not sure if this helps but I just tried running 'check settings.set' and then 'checkSetup' and the processing fails with the test data too. I'm guessing that this is some indication that there is something wrong with the installation but we can't seem to figure out what. I have attached a log file from the test run in case that helps shed some light.

Do let me know if you have any advice.
Thanks,
Diya

On Tue, Mar 31, 2015 at 4:24 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:
So I think he means leave DORIS the way it is but install a different version of adore as per the link below?

Let me know if you have any thoughts!
-Diya

---------- Forwarded message ----------
From: Batuhan Osmanoglu <batuhan....@gmail.com>
Date: Tue, Mar 31, 2015 at 3:40 PM
Subject: Re: [adore-doris] issues reading external DEM (ASTER)
To: Diya Chowdhury <dchow...@appliedgeosolutions.com>

Hello Diya,

In terms of DEM stuff, if on ubuntu can you try installing Antonio's package and test it with that Doris?
https://launchpad.net/~a.valentino/+archive/ubuntu/eotools

best,
batu

On Mon, Mar 30, 2015 at 10:07 AM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

Okay that is extremely weird. I am working on an Ubuntu machine. We installed DORIS (v4.06.2) from source:

http://doris.tudelft.nl/

and then Adore from the Ubuntu PPA package.

I also downloaded this patch for adore, which I can't seem to find the link to right now, so I have attached it to this email.

Does it look like anything is missing or incorrect? Let me know!

Thanks,
Diya

On Sat, Mar 28, 2015 at 4:46 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:
Hi Jon,

As suspected I think there might be an issue with the way we installed DORIS. Read below my latest email exchange with the developer. Let me know if you have any time on Monday to look into this?

Thanks,
-Diya

---------- Forwarded message ----------
From: Batuhan Osmanoglu <batuhan....@gmail.com>
Date: Sat, Mar 28, 2015 at 11:30 AM
Subject: Re: [adore-doris] issues reading external DEM (ASTER)
To: Diya Chowdhury <dchow...@appliedgeosolutions.com>

Hi Diya,

Not sure why DORIS fails on your computer, but on mine it worked fine. with the DEM I sent earlier. See the output below...

I am beginning to suspect the compilation. How was the DORIS code compiled? Is it installed from a package?

best,
batu.
--
ADORE: cp ~/Dropbox/Public/DEM.tar.bz2 .
ADORE: bunzip2 DEM.tar.bz2
ADORE: tar -xvf DEM.tar
DEM.prj
DEM.bil
DEM.hdr
ADORE: dem load DEM.bil
You are using ESRI .hdr labelled *.BIL format as DEM.
I expect to find the header file at: ./DEM.hdr
Loading settings for sam_, dac_, and crd_
ADORE: dem view
ADORE: undo only m_simamp
sim_amplitude found at 170 in ./20140702.res
Undo Successful.
ADORE: m_simamp

INFO : @(#)Doris InSAR software, $Revision: 4.06.2 $, $Author: TUDelft $
INFO : input file: "./m_simamp.drs"
INFO : Current time: Sat Mar 28 11:17:43 2015

INFO : SCREEN: verboseness: INFO
INFO : BEEP: beeping disabled
INFO : PREVIEW: OFF: generation of SUNraster files disabled.
INFO : ORB_INTERP: polynomial fit for interpolation
INFO : ORB_PRM: identified, using position state vectors for orbit interpolation
INFO : PROCESS: I will process step: M_SIMAMP
INFO : STOP: Encountered.
INFO :
*** General input cards ***
INFO : MEMORY: Available to Doris [MB]: 500
INFO : M_RESFILE: Resultfile for master: ./20140702.res
INFO : S_RESFILE: Resultfile for slave: ./.res
INFO : I_RESFILE: Resultfile for products: ./20140702_.res
INFO : LOGFILE: Out file for logging: ./default.log
INFO : ORB_INTERP: method selector value: -12
INFO : ORB_PRM: orbit parameters selection value: 30
INFO : DUMPBASELINE: evaluation grid for baseline: 1 lines x 1 pixels:
INFO : HEIGHT: average terrain height: 0
INFO : TIEPOINT: lat/lon/hei: 0 0 0
INFO : LISTINPUT: Append input to logfile: 1
INFO : ELLIPSOID: Ellipsoid used (orbit, output): WGS84.
INFO : ELLIPSOID: a = 6378137
INFO : ELLIPSOID: b = 6356752.3141
INFO : ELLIPSOID: e2 = 0.006694380035513
INFO : ELLIPSOID: e2' = 0.006739496788262
INFO :
*** Input for step SIMAMP ***
INFO : SAM_IN_DEM: DEM.bil
INFO : SAM_OUT_THETA_LP: ./20140702.samthetalp; output requested of incidence angle THETA [rad] in radar coordinates.
INFO : SAM_OUT_DEM_LP: ./20140702.samdemlp; output requested of DEM [m] in radar coordinates.
INFO : SAM_OUT_DEM: ./20140702.samdem; output requested of input DEM.
INFO : SAM_OUT_FILE: ./20140702.sam; output requested of simulated amplitude.
INFO : SAM_IN_SIZE: 7201 10801; number of rows (latitude), columns (lon) in DEM.
INFO : SAM_IN_UL: 70 18; coordinates of upper left corner (first row/col).
INFO : SAM_IN_DELTA: 0.000278 0.000278
INFO : SAM_IN_NODATA: -9999; this number in DEM will be set to 0 reference phase.
INFO : SAM_IN_FORMAT: input format DEM: real4.
PROGRESS: Interpretation inputoptionsfile finished.
PROGRESS: Interpretation inputoptionsfile finished.
INFO : Little Endian machine defined and this is correct.
INFO : strptime function works fine.
INFO : Current time: Sat Mar 28 11:17:43 2015

total cpu: 0 min 0.001161 sec
PROGRESS: Finished initialization
PROGRESS: Finished initialization
INFO : Reading parameters from: ./20140702.res
INFO : sec of day of first azimuth line: 58981.7
INFO : Checking file: ./20140702.res

INFO : Yeah, Radarsat-2!
INFO : Range to pixel 1 = 1057158.268 m
INFO : Range to pixel 4040 = 1076275.172 m

INFO : Doppler centroid frequency: at pixel 1 (early edge): 186.819 Hz
INFO : Doppler centroid frequency: at pixel 4040 (far edge): 202.932 Hz
INFO : Doppler centroid frequency: at pixel 62084.699 (maximum): 314.823 Hz

INFO : sensor: 70
[orbit.cc] orbvector_type: 30 vs velo prm fixed: 31

INFO : 5 datapoints (t,x,y,z) read from: "./20140702.res"

INFO : Setting default orbit interpolation method.
INFO : Computing coefficients for orbit polyfit degree: 3

INFO : Max. approximation error at datapoints (x,y,or z?): 4.78281e-06m
INFO : Max. approximation error at datapoints (x,y,or z?): 6.56641e-07m
INFO : Max. approximation error at datapoints (x,y,or z?): 1.49459e-05m

PROGRESS: Orbit: interpolation coefficients computed.
PROGRESS: Orbit: interpolation coefficients computed.
INFO :

INFO : master: latest known processing stage: crop
INFO : Checking file: ./20140702.crop

PROGRESS: Start SIMULATE AMPLITUDE.
PROGRESS: Start SIMULATE AMPLITUDE.
INFO : DEM input: w/e/s/n: 18/21.0024/67.9984/70
INFO : DEM input required: w/e/s/n: 18.6333/19.661/68.1598/68.6291
INFO : DEM input window (l0,lN,p0,pN): 4931 6620 2278 5975
INFO : For master window (l0,lN,p0,pN): 1 4796 1 4040
INFO : DEM output total pixels: 3698
INFO : DEM output total lines : 1690
INFO : Radar coding of DEM in: 1 buffers of 1690 lines and 0 extra buffer of 0 lines.

PROGRESS: SAM: Buffer# [l0:lN, p0:pN]: 1 [4931: 6620, 2278: 5975]
PROGRESS: SAM: Buffer# [l0:lN, p0:pN]: 1 [4931: 6620, 2278: 5975]

PROGRESS: SAM: Reading crop of DEM for buffer: 1
PROGRESS: SAM: Reading crop of DEM for buffer: 1
INFO : Read crop of input DEM: format: REAL4.
PROGRESS: Converting DEM to radar system for this buffer.
PROGRESS: Converting DEM to radar system for this buffer.

INFO : Number of points in DEM: 6249620

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 0 (0%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 0 (0%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 100 (6%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 100 (6%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 200 (12%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 200 (12%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 300 (18%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 300 (18%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 400 (24%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 400 (24%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 500 (30%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 500 (30%)

PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 600 (36%)
PROGRESS: SAM: Radarcoding buffer: 1of1 DEM line: 600 (36%)

PROGRESS: SAM: Reading input for interpolation buffer: 2of2
PROGRESS: SAM: Reading input for interpolation buffer: 2of2
INFO : griddataLinear interpolation.
PROGRESS: SAM: Writing radar coded SIM_AMPLITUDE to file, buffer#: 2 of 2
PROGRESS: SAM: Writing radar coded SIM_AMPLITUDE to file, buffer#: 2 of 2
INFO : Closing output files

INFO : Min. value of input DEM covering sim. amplitude (master): 317

INFO : Max. value of input DEM covering sim. amplitude (master): 1792
PROGRESS: Finished SIMULATE AMPLITUDE.
PROGRESS: Finished SIMULATE AMPLITUDE.

INFO : Current time: Sat Mar 28 11:18:46 2015

total cpu: 1 min 2.49332 sec

INFO :
INFO : master: latest known processing stage: simamplitude
PROGRESS: calling preview for simulated amplitude
PROGRESS: calling preview for simulated amplitude

INFO : Exiting dumporbit, no orbit data available.
INFO : No tiepoint given.
INFO : Current time: Sat Mar 28 11:18:46 2015

total cpu: 1 min 2.49435 sec

Processing results are in parameter file:
./20140702.res

...It is easier to square the circle than to get round a mathematician.

--- WARNING SUMMARY ---

--- WARNING SUMMARY ---

There were no messages.
There were no messages.

Normal termination.
Thank you for using Doris.

m_simamp: SUCCESS

ADORE:

On Fri, Mar 27, 2015 at 4:56 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:
Sure! I just added it to the dropbox folder.

Thanks,
Diya

On Fri, Mar 27, 2015 at 4:53 PM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:

Hi Diya,

Can you send me the result (*.res) file that has the information for this crop?

Best,
batu.

On Fri, Mar 27, 2015 at 2:39 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

I have put the m_crop result on dropbox. Here is the link:

Do let me know what your thoughts are. Thanks again for all the help!

Best,
Diya

On Fri, Mar 27, 2015 at 1:53 PM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:
Hi Diya,

Just the master would be fine. I can test the DEM with the m_simamp step.

I can either use the SLC, or the result of the m_crop step, which you can multilook to reduce file size. You can just zip the files or try using the "archive" command:
https://code.google.com/p/adore-doris/wiki/archive

Best,
Batu.

On Mar 27, 2015 1:41 PM, "Diya Chowdhury" <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

Sure, I am working with Radarsat 2 data in Sweden. I can definitely share the data with you, with the reassurance that you wouldn't further distribute it.
Would you need both master and slave data? Also, what would be the best way to share it with you? Each file is about 79MB.

Thanks,
Diya

Diya Chowdhury

unread,

Apr 6, 2015, 9:55:22 AM4/6/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for your email. I checked the interferogram for the test data like you suggested and it looks good, which must mean that the error is generated due to running it on a 64 bit machine (which I am). So I'm guessing this indicates that the installation was done correctly but I'm still not sure why we get the 'extend DEM to N and W' errors during simamp. Do you think that those errors are redundant as well and don't necessarily mean that the result is bad? Should I just continue processing regardless of those errors?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 6, 2015, 10:12:32 AM4/6/15

to Diya Chowdhury, adore...@googlegroups.com

Hello Diya,

So the 64-bit difference, I can explain quite well, but not sure about the DEM problem, since I can't reproduce it here.

Do a "view a m_simamp" in adore and see how it looks. If the image is too big you can enter multilook parameters with -M X/Y, X and Y being the multilook parameters.

If it looks OK, continue with m_timing and see what you get.

best,

batu.

Diya Chowdhury

unread,

Apr 6, 2015, 11:25:01 AM4/6/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Okay I will test it out and get back to you. Also another quick question, what type of machine are you running adore/doris on? It would be good to know what works best so that if all else fails we can just reinstall it on a machine we know it works on for sure.

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 6, 2015, 11:29:40 AM4/6/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

My setup is as follows:

Ubuntu 12.04/14.04

Intel 64-bit CPU

I also ran ADORE and DORIS on Centos 5 and 6, with Intel 64bit CPUs.

In the past I had a AMD 64bit machine with Ubuntu. It also worked great except the md5sum differences with Intel.

Best,

batu.

Batuhan Osmanoglu

unread,

Apr 8, 2015, 2:13:07 PM4/8/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

You can use the view command to display a scale:

https://code.google.com/p/adore-doris/wiki/view

Use the "-b" switch for that...

For the values, 32767 is assigned to the empty cells. Mask that value (very easy in QGIS). And DORIS (or adore) does not flip the values so negative means, the distance between the ground and satellite got shorter, i.e. uplift...

best,

batu.

On Wed, Apr 8, 2015 at 2:04 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

Just an update, I think I figured out how to save it so that I can import it into GIS software. I am looking at the unwrapped image and the values seem to range from -56 to 32767. I'm a little confused about the units I guess. Also do -ve values mean subsidence or uplift?

Thanks for all the help, really appreciate it!

-Diya

On Wed, Apr 8, 2015 at 1:34 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

As recommended, I went ahead with the processing (with a different pair than I sent you) and it seems to have worked. I just finished unwrapping the phase. Do you know if there is any way I can add a scale to the unwrapped image? I'm not sure how to read the min/max deformation just from the colored image.

Thanks,
Diya

Batuhan Osmanoglu

unread,

Apr 8, 2015, 2:34:49 PM4/8/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

The view and raster show the results in radar coordinates. If you like to flip the image, you can use the "mirror" option:

   -m code           Flag to mirror file content in X or Y direction:
                     x | y | xy

It is not in mm, but in radians. If you like to convert to mm, you can open it in ipython and use something like:

ADORE: openInIpython

This will give you python prompt with several objects. see:

https://code.google.com/p/adore-doris/wiki/openInIpython

You can then load the result you want to load and convert it to mm by:

For example for unwrap step:

unw=adore.getProduct(iobj.unwrap)

matshow(insar.rad2dist(unw, wavelength=mobj.readfiles.Radar_wavelength)*1000)

Doris reports the wavelength in meters, if we like to convert to mm, we have to multiply it with 1000.

best,

batu.

On Wed, Apr 8, 2015 at 2:25 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Also, does the 'view' option flip the image? It appears to be flipped in N-S direction, compared to the 'saveas arcgis' result.

-Diya

On Wed, Apr 8, 2015 at 2:18 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:
Okay great, and it's in 'mm' right?

Batuhan Osmanoglu

unread,

Apr 9, 2015, 2:43:00 PM4/9/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Sorry to hear that. Do you have ipython installed? (check with "which ipython" or type "ipython --pylab" on the commandline)

If you do, it should work, because all ADORE does is run ipython with a start-up script.

Regardless here are my settings:

ADORE: s ADORE

ADOREFOLDER=/d0/bosmanoglu/projectLocker/adore-doris/trunk

ADORESCR=/d0/bosmanoglu/projectLocker/adore-doris/trunk/scr

ADORE: s PATH

PATH=/d0/bosmanoglu/projectLocker/adore-doris/trunk/scr:/d0/bosmanoglu/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/d0/bosmanoglu/bin/getSAR/bin:/d0/bosmanoglu/bin/getSAR/lib:/d0/bosmanoglu/bin:/usr/lib/gmt/bin:/d0/bosmanoglu/projectLocker/giant/GIAnT/SCR:/d0/bosmanoglu/bin/NEST4C-1.1

Best,

batu.

On Thu, Apr 9, 2015 at 2:21 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

Thanks for the info. I am having trouble running openInIpython and I think its because of the path variables. Could you send me a copy of what your $PATH, $ADORESCR and $ADOREFOLDER variables are set to?

Thanks,
Diya

Diya Chowdhury

unread,

Apr 9, 2015, 3:49:02 PM4/9/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Thanks Batu,

I moved a couple of files around and managed to get it to work! Just one more question, is there any quick way to output this "scaled" unwrapped output as a georeferenced image with adore/ipython? I would like to view it in qgis eventually.

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 9, 2015, 4:31:58 PM4/9/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

You can try "visualize" which is a python wrapper to display the data in a Lat/Lon Grid:

https://code.google.com/p/adore-doris/wiki/visualize

Something like:

ADORE: visualize map p slant2h

might work...

best,

batu.

Diya Chowdhury

unread,

Apr 9, 2015, 4:45:04 PM4/9/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks. I was looking for something more in terms of using the result I created in ipython with the insar.rad2dist function. I would like to output this result to a GIS friendly image/raster.

-Diya

Batuhan Osmanoglu

unread,

Apr 9, 2015, 4:56:57 PM4/9/15

to Diya Chowdhury, adore...@googlegroups.com

Oh got it...

Import the attached file, then you can use the writeTiff command.

Something like:

gis.writeTiff(YourArray, None, filename='test.tif', lon=longitudeArray, lat=latitudeArray, grid=True)

might work.

Longitude and Latitude are the phi and lam files from geocoding step. You can read them with something like:

adore.getProduct(iobj.geocoding, filename="somefilename.phi")

Alternatively, you can write the array you generated into a binary file with:

adore.writedata('mydata.r4', yourArray, 'r4')

and use the saveas command with ":" operator:

ADORE: saveas envi p slant2h:mydata.r4

or to get a geotiff

ADORE: saveas gdal p slant2h:mydata.r4 -of GTiff mydata.tif

Eventually the gis.py will be added to ADORE but is not well tested... Saveas method should work though.

best,

batu

gis.py

Diya Chowdhury

unread,

Apr 13, 2015, 2:50:39 PM4/13/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for all the info. I managed to create gtif images but I am still not convinced that the resultant interferogram is correct. Is there any way I can actually check this? After unwrapping I am getting deformation ranging from +126 to -126mm which seems highly unlikely in these regions.

Other than those DEM errors that I get during the m_simamp step, I also get these errors during the m_timing step. Anything I should be worried about?

There were 5 messages:

1: Check estimated offset coarse corr: it seems unreliable.

2: There are 4 offset pairs which has equal mode values are equal.

3: Check offset results and logs, and increase the number and/or the size of the correlation windows.

4: getmodeoffset: all the offset occurence == 1. There is no mode value.

5: (please check bottom of LOGFILE to see if offset is OK or change window size.)

Normal termination.

Thank you for using Doris.

m_timing: SUCCESS

from LOGFILE:

*******************************************************************

* MTIMING_CORRELATION: Offset Table

*******************************************************************

Correlation method: magspace

Number of correlation windows: 16

Correlation window size (l,p): 257, 129 (l forced odd) (p forced odd)

Searchwindow size (l,p): 321, 193

Number posl posp offsetl offsetp correlation

0 181 117 4 13 0.0415845

1 181 1132 -31 -14 0.143832

2 181 2147 -160 -96 -999

3 181 3162 -30 -14 0.08187

4 1659 371 -31 28 0.0233659

5 1659 1386 -160 -96 -999

6 1659 2401 -160 -96 -999

7 1659 3416 -14 27 0.131828

8 3137 624 -19 -21 0.229108

9 3137 1639 -29 -32 0.0460446

10 3137 2654 24 -25 0.0457064

11 3137 3669 -26 22 0.0152247

12 4615 878 -4 -32 0.0526279

13 4615 1893 14 2 0.0497663

14 4615 2908 20 -17 0.0496155

15 4615 3923 32 24 0.307803

Estimated total offset (l,p): -31, -14

Coherence NaN values are disregarded in the analysis.

*******************************************************************

Current time: Mon Apr 13 13:40:19 2015

*******************************************************************

* MTIMING_CORRELATION: Offset Frequency Table

*******************************************************************

Using following data to determine coarse image offset:

avg. coh offset_L offset_P occurence index

------------------------------------------------------

0.143832 -31 -14 1 3

0.229108 -19 -21 1 3

0.131828 -14 27 1 3

0.307803 32 24 1 3

*******************************************************************

Diya Chowdhury

unread,

Apr 13, 2015, 4:24:19 PM4/13/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Also, related to an earlier question: You mentioned required the Volume and possibly Null files in order to process Radarsat 1 data but those don't seem to be available for the L1 products. Would I need L0 then?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 13, 2015, 5:04:49 PM4/13/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Re: Radarsat-1

I worked with Radarsat-1 data quite a while back, and it was in CEOS format, which comes with four files: DAT, LEA, VOL, NUL

But things might have changed, though I haven't heard. What are the file extensions you have?

Re: MTiming

The correlation values are awfully low, so my guess is that the area does not have significant topography, or the 16 windows DORIS places on the images are not hitting areas where there is significant topographic variation to create a change in reflected power in the SLC.

You can take a look at the results of Subtrrefpha step (*.srp) and compare that with the *.crddemlp (you will have to wrap this, see view command, I think it is -q wrap option).

If there is significant DEM (due to topography + perpendicular baseline) you would see a some correlation. If not, you won't...

If you see a significant correlation, you can try moving the DEM around and finding where the residual phase (*.srd) gets small.

Also not sure if you are doing time series or single pair, but if you are doing single pair, and your signal is small (few mm) your image will more likely be dominated by atmospheric phase contribution.

All the best,

batu

Diya Chowdhury

unread,

Apr 14, 2015, 9:05:45 AM4/14/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for the info regarding Radarsat2.

As for Radarsat1, the L1 product consists of *.P, *.L, *.L.txt, *.kml, *.jpg, *.D files. The L0 product consists of *.vol, *.tlr, *.raw, *.pi, *.nil, *.meta, *.ldr files.

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 14, 2015, 12:49:12 PM4/14/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

I think we are getting communication mishaps ;)

So the file names I mentioned (DAT, LEA, NUL, VOL) are for Radarsat-1 CEOS format.

Radarsat-2 has a different file format. DORIS uses GDAL to read the SLC. See the rs2_dump_data.py and rs2_dump_header2doris.py files in the bin folder. I recommend you run them by hand to make sure they are generating what you expect.

Also I highly recommend you check the amplitude master/slave images with adore to make sure the files are read properly. You can use either view or raster.. Add some multilooking (-M) to help with memory usage (especially for view).

If the radar intensity looks good for both master and slave, try to do a coarsecorr, fine etc, without the m_simamp and m_timing, to make sure you can get a simple interferogram first...

I never had access to Radarsat-2 data, so I haven't done it, but if you can read the files properly, the rest is (almost) sensor independent and should work.

best,

batu

On Apr 14, 2015 10:33 AM, "Diya Chowdhury" <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

We are not sure. We are using preprocessed Radarsat2 SLC data (CSA and MDA). I was under the impression that adore-doris could only handle L1 Radarsat2 data?

-Diya

On Tue, Apr 14, 2015 at 9:24 AM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:

Hi Diya,

How was the radarsat 2 data focused? Which software etc?

Best,
Batu

...

Diya Chowdhury

unread,

Apr 14, 2015, 4:43:43 PM4/14/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Sorry for the confusion. The filenames I mentioned are indeed for Radarsat 1 CEOS format SLC (.P, .L, .L.txt, .kml, .jpg, and .D). I don't see any dat,nul or vol files. Has no one else had this issue?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 14, 2015, 6:30:12 PM4/14/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

I am not familiar with that format for Radarsat 1 data. If there is a sample image I can look into it but can not do it anytime soon...

About the Radarsat 2 results. I am guessing the location of the geocoded result is wrong right? If you haven't checked please generate a gecoded amplitude file using saveas and verify. Basically I think there is a large offset between image and dem causing poor topography removal.

You were also asking about the large signal in unwrapped image. I think after the dem is removed correctly it will improve. Also how was the interferogram filtered? If you used goldstein I would recommend trying modgoldstein.

Best,
Batu

Diya Chowdhury

unread,

Apr 16, 2015, 12:41:02 PM4/16/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

I think you are right about their being an offset between the DEM and image. Yes I did take a look at the geocoded amplitude file and it looks off; shifted slightly E and S, which would explain the 'extend DEM to the N and W' errors. Do you think adore is having trouble reading the DEM correctly? So far I've been feeding it .bil format, maybe I should try .grd or .flt? Do you have any suggestions on how to fix this offset?

To filter the interferogram i just used the 'filtphase' command. How do I change it to modgoldstein? I don't see any options for user settings in filtphase.

Thanks,

Diya

--
You received this message because you are subscribed to a topic in the Google Groups "ADORE-DORIS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adore-doris/841IKGnO3_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adore-doris...@googlegroups.com.

Batuhan Osmanoglu

unread,

Apr 16, 2015, 1:21:43 PM4/16/15

to Diya Chowdhury, adore...@googlegroups.com

Hello Diya,

The first order (without simamp/m_timing) DEM offset calculation is done purely based on orbits, assuming the height given in the height parameter. I don't remember now if your average height was significantly above 0, but if so, you may want to change the height parameter and re-run..

To fix the offset between the DEM and the Master image, you would normally use simamp/m_timing, but since they are failing you can do manually. To do this simply set the mte_method to manual, and re-run that step. You should get two displays, one showing the *.sam file and the other showing the *.crop file. As usual you can use "-M" flag to multilook the image to make it use less memory.

Then you can left click on each image to select the points you think are the same (mountain peaks etc.). Once you set the location of both points (shown by blue lines) you can right click to accept this point. ADORE prompt will list the pixel values from both images, along with a correlation value...

Once you select some points (~10) you can close both figures, and ADORE will try to estimate the timing offsets and generate a result for m_timing step in the result file.

Let me know if it works or not. If you roughly know how many pixels you need to shift the SAR image in azimuth (line) and range (pixel) you can also look at the following file, calculate the timing offsets manually, and modify your existing m_timing results:

https://github.com/bosmanoglu/adore-doris/blob/master/lib/python/fun/manual_offsets_timing_error.py

For modgoldstein, you have to set:

pf_blocksize=32

pf_method=modgoldstein

pf_overlap=15

Please make sure overlap=blocksize/2-1. Otherwise you will get checkerboard effects.

Best,

batu.

Diya Chowdhury

unread,

Apr 16, 2015, 1:47:35 PM4/16/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for explaining the manual method to me, I will give it a go, but just quick update: good news - I tried installing adore/doris on a different machine and I don't get those m_simamp errors (extend to N and W) but I do get some errors in m_timing:

--- WARNING SUMMARY ---

There were 7 messages:

1: Check estimated offset coarse corr: it seems unreliable.

2: There are 6 offset pairs which has equal mode values are equal.

3: Check offset results and logs, and increase the number and/or the size of the correlation windows.

4: getmodeoffset: mean coherence of estimates used < 0.2

5: (please check bottom of LOGFILE to see if offset is OK)

6: getmodeoffset: all the offset occurence == 1. There is no mode value.

7: [...]

Normal termination.

Thank you for using Doris.

m_timing: SUCCESS

FROM LOGFILE:

*******************************************************************

* MTIMING_CORRELATION: Offset Table

*******************************************************************

Correlation method: magspace

Number of correlation windows: 16

Correlation window size (l,p): 257, 129 (l forced odd) (p forced odd)

Searchwindow size (l,p): 321, 193

Number posl posp offsetl offsetp correlation

0 181 117 11 -17 0.0415696

1 181 1132 -21 -17 0.11927

2 181 2147 -160 -96 -999

3 181 3162 31 -16 0.0737865

4 1661 371 17 -3 0.0231323

5 1661 1386 25 -31 0.0115191

6 1661 2401 25 -32 0.0224933

7 1661 3416 -17 -23 0.0864939

8 3141 624 -18 -11 0.087981

9 3141 1639 -160 -96 -999

10 3141 2654 8 -29 0.0337261

11 3141 3669 32 -15 0.145957

12 4621 878 -29 -20 0.018957

13 4621 1893 11 14 0.0325553

14 4621 2908 32 -22 0.131948

15 4621 3923 -32 26 0.219336

Estimated total offset (l,p): -32, 26

Coherence NaN values are disregarded in the analysis.

*******************************************************************

* MTIMING_CORRELATION: Offset Frequency Table

*******************************************************************

Using following data to determine coarse image offset:

avg. coh offset_L offset_P occurence index

------------------------------------------------------

0.219336 -32 26 1 2

0.11927 -21 -17 1 2

0.087981 -18 -11 1 2

0.0864939 -17 -23 1 2

0.131948 32 -22 1 2

0.145957 32 -15 1 2

*******************************************************************

I don't fully understand these error messages or what affect they have on the processing. You also mentioned that usually the offset is fixed using m_simamp and m_timing so I thought I would ask to see how it is done since they seem to be working for me now?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 16, 2015, 2:04:51 PM4/16/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

It is basically telling you that your correlations are very low:

1: Check estimated offset coarse corr: it seems unreliable.

getmodeoffset: mean coherence of estimates used < 0.2

etc... Basically it is saying that m_timing failed to find a good match between simamp and m_crop.

If you want to make m_timing work, I recommend that you increase the mte_winsize, mte_nwin, and mte_acc parameters. Set mte_acc to be half of mte_winsize... I am guessing the DEM is far off enough that m_timing is not able to find matching points in the window.

Once you increase these values (to say double what they are), things will slow down.

I have gotten it to work in the past this way, but only if you can visually see matching features in simamp and m_crop.

Best,

batu

Diya Chowdhury

unread,

Apr 16, 2015, 4:51:08 PM4/16/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for the info. I know this is a silly question but everytime I try and change the above mentioned parameters in the m_timing.drs file, it gets overwritten with a new m_timing.drs file with the default params at the time of running m_timing in adore. Is there some trick to forcing adore to use a .drs file that the user sets?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 16, 2015, 4:59:07 PM4/16/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Not a silly question at all ;)

Parameter management within ADORE is done using the "settings" command. Which can load, save, and change parameters.

If you already have a drs file and want to use that, simply call "doris m_timing.drs"

Best,

batu.

Diya Chowdhury

unread,

Apr 17, 2015, 9:10:57 AM4/17/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

So I am looking at the m_crop and m_simamp (using 'view') and it looks to me as though the m_simamp is a little stretched out? Do you think this is why the m_timing keeps failing? Any idea why this is happening?

Thanks,

Diya

m_crop.png

m_simamp.png

Batuhan Osmanoglu

unread,

Apr 17, 2015, 9:58:02 AM4/17/15

to Diya Chowdhury, adore...@googlegroups.com

Hello Diya,

Yes, you found the problem. Simamp is definitely stretched.. It seems like it is stretched in both Azimuth and Range directions right? This would be related to some parameter being read wrong. For azimuth my first guess is PRF. For example if PRF is twice what it should be, DORIS may think that satellite took half the time to acquire total number of pulses, making it also think that satellite is traveling only half the distance using the orbits. Similarly Range Sampling Rate can be wrong for range stretching...

But that means two errors and I would think it is unlikely, unless the parameters are read wrong. Can you please check the values written in the result of m_readfiles and see if they are what you expect?

Another option may be the orbit interpolation going wrong. I once had a very weird case of orbit values written wrong in the header file by a commercial processor, making Doris go nuts... I don't know what the interval will be in the result file, but you should be able to differentiate the X, Y, and Z values in time, and get values in the same ballpark for each interval (i.e. satellite velocity does not change too rapidly).

Another option may be that simply the DEM resolution is wrong. For example if Doris thinks the DEM has 30m pixels instead of 15m, it will take half the number of pixels for the image.. Can you please check that?

Let me know if none of the above make sense/is wrong. There might be other explanations, but these come to my mind at the moment.

Best,

batu.

Diya Chowdhury

unread,

Apr 17, 2015, 4:23:15 PM4/17/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

Thanks for your reply. Good to know we're atleast narrowing down on what's wrong. I looked at the result of the m_readfile and s_readfile. Here are the specs:

Leader file: product.xml

Sensor platform mission identifer: RADARSAT-2

Scene_centre_latitude: 6.844759999999999e+01

Scene_centre_longitude: 1.913650000000000e+01

Scene_centre_heading: Null

Radar_wavelength (m): 0.055465772433

First_pixel_azimuth_time (UTC): 19-Aug-2014 16:23:01.265027

Pulse_Repetition_Frequency (computed, Hz): 2.598877441406250e+03

Total_azimuth_band_width (Hz): 9.000000000000000e+02

Weighting_azimuth: KAISER

Xtrack_f_DC_constant (Hz, early edge): 1.588683830720000e+02

Xtrack_f_DC_linear (Hz/s, early edge): -4.810416133900000e+04

Xtrack_f_DC_quadratic (Hz/s/s, early edge): 9.985700735200001e+06

Range_time_to_first_pixel (2way) (ms): 7.052600822266183

Range_sampling_rate (computed, MHz): 31.669922

Total_range_band_width (MHz): 30.02442

Weighting_range: KAISER

I tallied them with the leader file and they seem correct. The only thing I'm not sure of is the Range_sampling_rate as it appears that is computed? I'm not sure what the value should be.

Thanks,

Diya

Diya Chowdhury

unread,

Apr 17, 2015, 4:35:08 PM4/17/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Also I checked the resolution of the dem by doing 's crd_','s sam_', 's dac_' and they all look right ~ 30m.

Batuhan Osmanoglu

unread,

Apr 19, 2015, 6:18:54 AM4/19/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

OK then the only other thing we should check is the orbit information. Can you please copy paste the orbit information for the master scene. It will be a bunch of numbers towards the end of the m_readfiles step.

best,

batu.

Diya Chowdhury

unread,

Apr 20, 2015, 9:32:38 AM4/20/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Sure here you go:

ADORE: m_readfiles

INFO : @(#)Doris InSAR software, $Revision: 4.06.2 $, $Author: TUDelft $

INFO : input file: "./m_readfiles.drs"

INFO : Current time: Mon Apr 20 08:30:04 2015

INFO : SCREEN: verboseness: INFO

INFO : BEEP: beeping disabled

INFO : PREVIEW: OFF: generation of SUNraster files disabled.

INFO : ORB_INTERP: polynomial fit for interpolation

INFO : ORB_PRM: identified, using position state vectors for orbit interpolation

INFO : PROCESS: I will process step: M_READFILES

INFO : STOP: Encountered.

INFO :

*** General input cards ***

INFO : MEMORY: Available to Doris [MB]: 500

INFO : M_RESFILE: Resultfile for master: ./20140726.res

INFO : S_RESFILE: Resultfile for slave: ./20140819.res

INFO : I_RESFILE: Resultfile for products: ./20140726_20140819.res

INFO : LOGFILE: Out file for logging: ./test.log

INFO : ORB_INTERP: method selector value: -12

INFO : ORB_PRM: orbit parameters selection value: 30

INFO : DUMPBASELINE: evaluation grid for baseline: 1 lines x 1 pixels:

INFO : HEIGHT: average terrain height: 0

INFO : TIEPOINT: lat/lon/hei: 0 0 0

INFO : LISTINPUT: Append input to logfile: 1

INFO : ELLIPSOID: Ellipsoid used (orbit, output): WGS84.

INFO : ELLIPSOID: a = 6378137

INFO : ELLIPSOID: b = 6356752.3141

INFO : ELLIPSOID: e2 = 0.006694380035513

INFO : ELLIPSOID: e2' = 0.006739496788262

INFO :

*** Input for step M_READFILES (master) ***

INFO : M_IN_METHOD: method selected for master: 70

INFO : M_IN_VOL: Volumefile of master: dummy

INFO : M_IN_LEA: Leaderfile of master: /home/dchowdhury/RSAT2/data/20140726/product.xml

INFO : M_IN_NULL: Nullfile of master: dummy

INFO : M_IN_DAT: Datfile of master: /home/dchowdhury/RSAT2/data/20140726/imagery_HH.tif

PROGRESS: Interpretation inputoptionsfile finished.

INFO : Little Endian machine defined and this is correct.

INFO : strptime function works fine.

INFO : Current time: Mon Apr 20 08:30:04 2015

total cpu: 0 min 0 sec

PROGRESS: Finished initialization

PROGRESS: Start M_READFILES.

INFO : With following command the Radarsat-2 header was read.

INFO : rs2_dump_header2doris.py /home/dchowdhury/RSAT2/data/20140726/product.xml > scratchres_rs2

PROGRESS: Making system call to rs2_dump_header2doris.py

PROGRESS: (also requires python, gdal and XML libraries)

PROGRESS: Finished system call to rs2_dump_header2doris.py

PROGRESS: Finished M_READFILES.

INFO : Current time: Mon Apr 20 08:30:04 2015

total cpu: 0 min 0 sec

INFO : Reading parameters from: ./20140726.res

INFO : sec of day of first azimuth line: 58981.4

INFO : Checking file: ./20140726.res

INFO : Yeah, Radarsat-2!

INFO : Range to pixel 1 = 1057158.268 m

INFO : Range to pixel 4040 = 1076275.172 m

INFO : Doppler centroid frequency: at pixel 1 (early edge): 145.671 Hz

INFO : Doppler centroid frequency: at pixel 4040 (far edge): 154.706 Hz

INFO : Doppler centroid frequency: at pixel 60754.136 (maximum): 215.955 Hz

INFO : sensor: 70

[orbit.cc] orbvector_type: 30 vs velo prm fixed: 31

INFO : 5 datapoints (t,x,y,z) read from: "./20140726.res"

INFO : Setting default orbit interpolation method.

INFO : Computing coefficients for orbit polyfit degree: 3

INFO : Max. approximation error at datapoints (x,y,or z?): 1.85287e-06m

INFO : Max. approximation error at datapoints (x,y,or z?): 4.15603e-07m

INFO : Max. approximation error at datapoints (x,y,or z?): 1.08946e-05m

PROGRESS: Orbit: interpolation coefficients computed.

INFO : Exiting dumporbit, no orbit data available.

INFO : No tiepoint given.

INFO : Current time: Mon Apr 20 08:30:04 2015

total cpu: 0 min 0 sec

Processing results are in parameter file:

./20140726.res

...Looking at wrapped interferograms is like running in circles.

--- WARNING SUMMARY ---

There were no messages.

Normal termination.

Thank you for using Doris.

m_readfiles: SUCCESS

Also I should mention: at the very beginning, I didn't enter a range or az resolution value in the settings file. Should I be doing that?

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 20, 2015, 4:12:55 PM4/20/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

Not quite... Seems like you are missing the orbit information.

Here is an example section showing orbit information for ALOS...

*******************************************************************

*_Start_leader_datapoints

*******************************************************************

t(s) X(m) Y(m) Z(m)

NUMBER_OF_DATAPOINTS: 28

18120 -356223.3399011 -6250377.26444 -3304516.379124

18180 -467685.4776743 -6438265.915103 -2905081.850403

18240 -578791.1644951 -6599261.864419 -2493865.79127

18300 -688853.9218307 -6732711.42527 -2072531.510973

18360 -797185.9446727 -6838078.063771 -1642785.053338

18420 -903101.9562202 -6914944.839259 -1206368.212258

18480 -1005923.083075 -6963016.310662 -765051.3521455

18540 -1104980.722731 -6982119.874549 -320626.0756936

18600 -1199620.382748 -6972206.547224 125102.2106719

18660 -1289205.479759 -6933351.190513 570321.8214841

18720 -1373121.068284 -6865752.158268 1013222.376168

18780 -1450777.468038 -6769730.359619 1452002.396667

18840 -1521613.766201 -6645727.741291 1884876.875003

18900 -1585101.176789 -6494305.199313 2310084.768419

18960 -1640746.241671 -6316139.924941 2725896.377188

19020 -1688093.849217 -6112022.218995 3130620.56524

19080 -1726730.038581 -5882851.791956 3522611.794715

19140 -1756284.583077 -5629633.563215 3900276.927407

19200 -1776433.351042 -5353473.001684 4262081.7466

19260 -1786900.442811 -5055571.08142 4606557.196556

19320 -1787460.092586 -4737218.851574 4932305.362931

19380 -1777938.311326 -4399791.610774 5238005.154543

19440 -1758214.257971 -4044742.697207 5522417.650575

19500 -1728221.322707 -3673596.936016 5784391.023083

19560 -1687947.911851 -3287943.860943 6022865.042987

19620 -1637437.95156 -2889430.728119 6236875.195478

19680 -1576791.116787 -2479755.361033 6425556.397433

19740 -1506162.794064 -2060658.846186 6588146.347221

*******************************************************************

* End_leader_datapoints:_NORMAL

*******************************************************************

You should have something similar in the master and slave result files otherwise Doris wouldn't know where the satellite was during imaging...

Best,

batu.

On Mon, Apr 20, 2015 at 4:09 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:

Hi Batu,

I apologize, I'm afraid my last reply was a little premature. I had run the doris.rm_step.sh to get that output for m_readfiles hence the missing info in the result file. I just ran m_readfiles,m_crop and m_simamp and here is the result of m_readfiles:

ADORE: s result m_readfiles
*_Start_readfiles:
*******************************************************************
Volume file: product.xml

Volume_ID: PDS_03829590
Volume_identifier: RN-RP-51-2713, Issue 1/11
Volume_set_identifier: DUMMY
(Check)Number of records in ref. file: 5517
SAR_PROCESSOR: RN CAPPS SAR 1.1
SWATH: Q25
PASS: Ascending
IMAGING_MODE: FQ25 HH VV HV VH
RADAR_FREQUENCY (Hz): 5404999242.769673

Product type specifier: RADARSAT-2
Logical volume generating facility: GSS
Logical volume creation date: 2014-07-27T19:51:18.000000Z
Location and date/time of product creation: 2014-07-26T16:23:01.089416Z
Scene identification: Orbit: 34530 2014-07-26T16:23:01.449925Z
Scene location: lat: 68.4477 lon: 19.1412

Leader file: product.xml
Sensor platform mission identifer: RADARSAT-2

Scene_centre_latitude: 6.844770000000000e+01
Scene_centre_longitude: 1.914120000000000e+01

Scene_centre_heading: Null
Radar_wavelength (m): 0.055465772433

First_pixel_azimuth_time (UTC): 26-Jul-2014 16:23:01.449925

Pulse_Repetition_Frequency (computed, Hz): 2.598877441406250e+03
Total_azimuth_band_width (Hz): 9.000000000000000e+02
Weighting_azimuth: KAISER

Xtrack_f_DC_constant (Hz, early edge): 1.456710540103000e+02
Xtrack_f_DC_linear (Hz/s, early edge): 7.327544442676030e+04
Xtrack_f_DC_quadratic (Hz/s/s, early edge): -1.909851531800000e+07

Range_time_to_first_pixel (2way) (ms): 7.052600822266183
Range_sampling_rate (computed, MHz): 31.669922
Total_range_band_width (MHz): 30.02442
Weighting_range: KAISER

*******************************************************************
Datafile: imagery_HH.tif
Dataformat: GeoTIFF
Number_of_lines_original: 4802
Number_of_pixels_original: 4040
*******************************************************************
* End_readfiles:_NORMAL

Is this what you are looking for?

-Diya

On Mon, Apr 20, 2015 at 4:05 PM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:

Hi Diya,

Did you run m_porbits?

There shouldn't be any precise orbits available for Radarsat-2, so we should use the orbits in the leader file, which should be listed in the m_readfiles.

If you don't see any orbit information in the $m_resfile, that would be our problem. And it would likely because something went wrong with rs2_dump_header2doris.py. I would recommend running that individually to find out if it throws out an error message.

Try this command as a starting point:
rs2_dump_header2doris.py /home/dchowdhury/RSAT2/data/20140726/product.xml

best,
batu

On Mon, Apr 20, 2015 at 4:00 PM, Diya Chowdhury <dchow...@appliedgeosolutions.com> wrote:
Ah okay. Well this is interesting. I don't see those lines anywhere in the resultfile:

ADORE: s result m_readfiles

*_Start_readfiles:
*******************************************************************
Volume file: product.xml

Volume_ID: PDS_03829590
Volume_identifier: RN-RP-51-2713, Issue 1/11
Volume_set_identifier: DUMMY
(Check)Number of records in ref. file: 5517
SAR_PROCESSOR: RN CAPPS SAR 1.1
SWATH: Q25
PASS: Ascending
IMAGING_MODE: FQ25 HH VV HV VH
RADAR_FREQUENCY (Hz): 5404999242.769673

Product type specifier: RADARSAT-2
Logical volume generating facility: GSS
Logical volume creation date: 2014-07-27T19:51:18.000000Z
Location and date/time of product creation: 2014-07-26T16:23:01.089416Z
Scene identification: Orbit: 34530 2014-07-26T16:23:01.449925Z
Scene location: lat: 68.4477 lon: 19.1412

Leader file: product.xml
Sensor platform mission identifer: RADARSAT-2

Scene_centre_latitude: 6.844770000000000e+01
Scene_centre_longitude: 1.914120000000000e+01

Scene_centre_heading: Null
Radar_wavelength (m): 0.055465772433

First_pixel_azimuth_time (UTC): 26-Jul-2014 16:23:01.449925

Pulse_Repetition_Frequency (computed, Hz): 2.598877441406250e+03
Total_azimuth_band_width (Hz): 9.000000000000000e+02
Weighting_azimuth: KAISER

Xtrack_f_DC_constant (Hz, early edge): 1.456710540103000e+02
Xtrack_f_DC_linear (Hz/s, early edge): 7.327544442676030e+04
Xtrack_f_DC_quadratic (Hz/s/s, early edge): -1.909851531800000e+07

Range_time_to_first_pixel (2way) (ms): 7.052600822266183
Range_sampling_rate (computed, MHz): 31.669922
Total_range_band_width (MHz): 30.02442
Weighting_range: KAISER

*******************************************************************
Datafile: imagery_HH.tif
Dataformat: GeoTIFF
Number_of_lines_original: 4802
Number_of_pixels_original: 4040
*******************************************************************
* End_readfiles:_NORMAL

Any clue why?

-Diya

On Mon, Apr 20, 2015 at 3:52 PM, Batuhan Osmanoglu <batuhan....@gmail.com> wrote:

Hi Diya,

The make dem scripts actually use the range/azimuth settings if they are defined. But once the DEM is generated DORIS takes over and calculates the area properly (given orbits, PRF, RSR etc.). So even though not having the correct resolutions can create generation of a larger/smaller DEM, DORIS steps like simamp etc. should read the DEM properly.

Sorry if I mis-directed you earlier. The orbits are in the portion that starts with:
*_Start_leader_datapoints
...
and ends with:
* End_leader_datapoints:_NORMAL

It should be in the master result file, which can be displayed with:
ADORE: s result m_readfiles

best,
batu.

Diya Chowdhury

unread,

Apr 21, 2015, 11:29:11 AM4/21/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

I see. Okay I ran rs2_dump_header2doris.py as you recommended and here is the result. What do you think?

*******************************************************************

*_Start_leader_datapoints: DEF.ORB

*******************************************************************

t(s) X(m) Y(m) Z(m) X_V(m/s) Y_V(m/s) Z_V(m/s)

NUMBER_OF_DATAPOINTS: 5

58981.08900 2.850487709273430e+06 2.148662215230392e+05 6.567449341093404e+06 -6.102055403494067e+03 -3.465657419811361e+03 2.755928945643900e+03

58982.15050 2.844008367602576e+06 2.111877982890483e+05 6.570370751543089e+06 -6.105840996457932e+03 -3.464955498872733e+03 2.748376633740718e+03

58983.21200 2.837525011482527e+06 2.075101226991173e+05 6.573284143487582e+06 -6.109619128387371e+03 -3.464248764343159e+03 2.740820935150736e+03

58984.27350 2.831037648828126e+06 2.038331998661791e+05 6.576189513223311e+06 -6.113389798112784e+03 -3.463537215490305e+03 2.733261849333397e+03

58985.33500 2.824546287575993e+06 2.001570348984185e+05 6.579086857173712e+06 -6.117153004167452e+03 -3.462820851428284e+03 2.725699375635121e+03

*******************************************************************

* End_leader_datapoints:_NORMAL

*******************************************************************

Thanks,

Diya

Batuhan Osmanoglu

unread,

Apr 21, 2015, 5:45:30 PM4/21/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

The numbers look OK.

You can either copy paste that into the resultfile or find out why it is not in there to begin with.

Either way once you add it I think your results will change for better.

Best,
Batu

Diya Chowdhury

unread,

Apr 22, 2015, 9:24:52 AM4/22/15

to Batuhan Osmanoglu, adore...@googlegroups.com

Hi Batu,

I just noticed something odd. Earlier I was using s reslult m_readfiles to display the result and it was missing the 'sar_leader_datapoints' but just now when I opened up the .res file to edit it, the 'sar_leader_datapoints' are already in it. Do you think there is some issue where it's not reading the result file correctly in doris/adore?

-Diya

Batuhan Osmanoglu

unread,

Apr 22, 2015, 10:53:46 AM4/22/15

to Diya Chowdhury, adore...@googlegroups.com

Hi Diya,

That seems like a bug for Adore. If you can send me the result file I can try to see where the problem is.

If the values are in the file Doris would read them.

I am not sure what the problem may be for your data. I will write back if I can think of something.

All the best,
Batu.

Reply all

Reply to author

Forward