<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/">
  <title>SAR Discussions</title>
  <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_category?p_l_id=10348&amp;categoryId=11762" />
  <subtitle>Everything SAR</subtitle>
  <entry>
    <title>RE: 700 m bias between the ERS-Tandem DEM and SRTM-C DEM</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=437397" />
    <author>
      <name>Luyi Sun</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=437397</id>
    <updated>2013-05-14T12:33:21Z</updated>
    <published>2013-05-14T12:33:21Z</published>
    <summary type="html">&lt;div class='quote-title'&gt;Andrea Minchella:&lt;/div&gt;&lt;div class='quote'&gt;&lt;div class='quote-content'&gt;Dear Luyi,&lt;br /&gt;&lt;br /&gt;the DEM output from the exercise is &lt;b&gt;still relative height&lt;/b&gt;. &lt;br /&gt;To get absolute height you should hock it to a point which you know the &lt;br /&gt;absolute height and then correct the bias. &lt;br /&gt;&lt;br /&gt;A specific routine for doing this is not available in NEST, however once you know the bias, you could use the Band Maths operator for instance. &lt;br /&gt;&lt;br /&gt;Best regards,&lt;br /&gt;Andrea&lt;/div&gt;&lt;/div&gt;&lt;br /&gt;Dear Andrea,&lt;br /&gt;&lt;br /&gt;Thanks for your reply. As a new user of InSAR processing software, I don&amp;#039;t really understand how to get the absolute height. Although a routine for doing this is currently unavailable in NEST, could you give me an example (theoretically)?&lt;br /&gt;&lt;br /&gt;And what is the definition of the &amp;#034;relative height&amp;#034; as I found in NEST manual book that the height is corrected to wgs84 ellipsoid?&lt;br /&gt;&lt;br /&gt;Best regards,&lt;br /&gt;Luyi</summary>
    <dc:creator>Luyi Sun</dc:creator>
    <dc:date>2013-05-14T12:33:21Z</dc:date>
  </entry>
  <entry>
    <title>700 m bias between the ERS-Tandem DEM and SRTM-C DEM</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=437195" />
    <author>
      <name>Luyi Sun</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=437195</id>
    <updated>2013-05-13T00:38:42Z</updated>
    <published>2013-05-13T00:38:42Z</published>
    <summary type="html">Hi, I compared the elevation values of the DEM provided by the tutorial (which can be downloaded from the official FTP) with a SRTM-C DEM from the same scene. I found about 700 meters bias existing between the two DEMs, which is impossible resulting from the different coordinate system. Although the DEM generated by NEST is automatically corrected to WGS84  ellipsoid whilst SRTM-C is based on EGM96 Geoid, the undulation is only up to 100m. So I suspect the 700m bias is from the way NEST producing the DEM. Anyone got any ideas about this problem?</summary>
    <dc:creator>Luyi Sun</dc:creator>
    <dc:date>2013-05-13T00:38:42Z</dc:date>
  </entry>
  <entry>
    <title>RE: Example of processing for DEM generation via NEST and Snaphu: ppt avail</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=428785" />
    <author>
      <name>Nima Ahmadian</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=428785</id>
    <updated>2013-03-07T19:27:40Z</updated>
    <published>2013-03-07T19:27:40Z</published>
    <summary type="html">Dear Andrea&lt;br /&gt;&lt;br /&gt;In the presentation you mentioned that:&lt;br /&gt;The original data and full processing results (project) are freely available at: SFTP (port 22): nestbox.esrin.esa.int&lt;br /&gt;&lt;br /&gt;but unfortunately I am not able to access the link and download the data set&lt;br /&gt;&lt;br /&gt;would you please help me in this regard. Thank you in advance&lt;br /&gt;&lt;br /&gt;Best Regards&lt;br /&gt;Nima</summary>
    <dc:creator>Nima Ahmadian</dc:creator>
    <dc:date>2013-03-07T19:27:40Z</dc:date>
  </entry>
  <entry>
    <title>RE: Example of processing for DEM generation via NEST and Snaphu: ppt avail</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=428038" />
    <author>
      <name>Ismail Gf Gf</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=428038</id>
    <updated>2013-03-04T00:04:17Z</updated>
    <published>2013-03-04T00:04:17Z</published>
    <summary type="html">Dear All&lt;br /&gt;&lt;br /&gt;thank you for the processing slide. It is very useful and easy to follow.&lt;br /&gt;however, I&amp;#039;m stuck in unwrapping using snaphu. &lt;br /&gt;I install snaphu in Xubuntu, as guest Operating system in Virtual Box.&lt;br /&gt;I tried to run the script, but the process was terminated in the middle, and error message &amp;#034;out of memory&amp;#034; is appear on my screen. &lt;br /&gt;&lt;br /&gt;I crop the subset and the process went further, but still terminated before finishing the process.&lt;br /&gt;I set more memory for virtual box but it is just the same&lt;br /&gt;&lt;br /&gt;[IMG]http://i50.tinypic.com/nlq0dw.jpg[/IMG]&lt;br /&gt;&lt;br /&gt;Dos anyone know about this issue?&lt;br /&gt;&lt;br /&gt;thank you&lt;br /&gt;&lt;br /&gt;Regards</summary>
    <dc:creator>Ismail Gf Gf</dc:creator>
    <dc:date>2013-03-04T00:04:17Z</dc:date>
  </entry>
  <entry>
    <title>RE: What is Radarsat-2‘s data composition</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=422074" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=422074</id>
    <updated>2013-01-30T17:24:05Z</updated>
    <published>2013-01-30T17:24:05Z</published>
    <summary type="html">RS2 has one image per polarisation. Complex GeoTIFF has two bands real and imaginary.&lt;br /&gt;To read the imaginary part you must specify the second band. If band numbering starts from 0 then it would be band 1.</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2013-01-30T17:24:05Z</dc:date>
  </entry>
  <entry>
    <title>What is Radarsat-2‘s data composition</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=421363" />
    <author>
      <name>hao wei Xuan</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=421363</id>
    <updated>2013-01-29T11:11:08Z</updated>
    <published>2013-01-29T11:04:55Z</published>
    <summary type="html">Recently use GDAL to read RS2 data,while SLC format data always confuses me.I only can derive the real band data.Anyone helps me?How RS2&amp;#039; data organizes?</summary>
    <dc:creator>hao wei Xuan</dc:creator>
    <dc:date>2013-01-29T11:04:55Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS1 Sigma0 problem</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=411075" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=411075</id>
    <updated>2012-12-11T14:49:05Z</updated>
    <published>2012-12-11T14:49:05Z</published>
    <summary type="html">It sounds like the first two images have not been calibrated. After calibration (mostly constant calibration), the pixel value should be in range ~0.0-1.0.</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-12-11T14:49:05Z</dc:date>
  </entry>
  <entry>
    <title>RE: Object detection problems</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=411071" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=411071</id>
    <updated>2012-12-11T14:20:49Z</updated>
    <published>2012-12-11T14:20:49Z</published>
    <summary type="html">1) I&amp;#039;ll look into this. It should not matter if it has been geocoded or not.&lt;br /&gt;2) Shp file export is on our list to do&lt;br /&gt;3) You would need to add to the Abstracted Metadata a field called target_report_file with the path to the xml file&lt;br /&gt;4) I don&amp;#039;t follow what you mean?</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-12-11T14:20:49Z</dc:date>
  </entry>
  <entry>
    <title>ERS1 Sigma0 problem</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=410924" />
    <author>
      <name>Sabine Mann</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=410924</id>
    <updated>2012-12-11T08:36:18Z</updated>
    <published>2012-12-11T08:36:18Z</published>
    <summary type="html">We have auto coregistered a stack of 8 ERS1 images (apply orbit file, calibation to sigma0 and multilook has been applied). After speckle filtering of each image in the stack we would like to create a single band with the mean (average sigma0 over time). However, we have encountered a problem: The first two images (bands) in our stack have much higer values 1.0e7 whereas the last six have very small values ~0.0-1.0.&lt;br /&gt;Any solution is much appreciated ;-)</summary>
    <dc:creator>Sabine Mann</dc:creator>
    <dc:date>2012-12-11T08:36:18Z</dc:date>
  </entry>
  <entry>
    <title>RE: Example of processing for DEM generation via NEST and Snaphu: ppt avail</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=397062" />
    <author>
      <name>Jianwei Tao</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=397062</id>
    <updated>2012-10-17T04:27:06Z</updated>
    <published>2012-10-17T04:27:06Z</published>
    <summary type="html">thank you very much petar, you helped me a lot.&lt;br /&gt;&lt;br /&gt;just one thing, you said &amp;#034;Unfortunately, InSAR modules of NEST still do handle SpotLight TSX data.&amp;#034;  do or do not?&lt;br /&gt;&lt;br /&gt;Yesterday, I finished a test, using the two sets of TerraSar HS data of the famous Uluru of Australia (got from TSX website),&lt;br /&gt;&lt;br /&gt;I followed the tutorial&amp;#039;s procedure,  and got a pretty good result. But one step should be added, that is, before snaphu export, the&lt;br /&gt;coherence stack and filtered interference phase stack shall be further subseted, so that there is no dark part in both stacks. otherwise, the output of snaphu is a collection of strange strips.&lt;br /&gt;&lt;br /&gt;Another thing I noticed is that sanphu 1.4.2 did not support multi-core cpu on my Ubuntu 12.04, do you have a multi-core support version? or maybe i did not use some options when building snaphu?&lt;br /&gt;&lt;br /&gt;Here is my result:&lt;br /&gt;The first one is the created DEM shown in ENVI 3d surfaceview&lt;br /&gt;The second one is a snapshot of google earth at the image&amp;#039;s coverage place&lt;br /&gt;The third one is the created KMZ file shown in google earth.</summary>
    <dc:creator>Jianwei Tao</dc:creator>
    <dc:date>2012-10-17T04:27:06Z</dc:date>
  </entry>
  <entry>
    <title>RE: Example of processing for DEM generation via NEST and Snaphu: ppt avail</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=396858" />
    <author>
      <name>Jianwei Tao</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=396858</id>
    <updated>2012-10-16T10:10:57Z</updated>
    <published>2012-10-16T10:10:57Z</published>
    <summary type="html">As you said, if there is any question, it can be asked here.&lt;br /&gt;&lt;br /&gt;I repeated the whole process very smoothly, except for the snaphu period.&lt;br /&gt;&lt;br /&gt;My platform is Unbuntu 12.04 64-bit, with 4G memory and double 2.6G CPU.  It took me some time to get the Nest-4C running normal.  but snaphu had run for several hours, it seemed that it ran into dead lock. &lt;br /&gt;&lt;br /&gt;So I shut the sanphu, and repeated your processing procedure second time, with small subsets (1400X3000), everything was OK.  ( the result can be  shown in google earth)&lt;br /&gt;&lt;br /&gt;the readme of snaphu said that 100M memory for 1 million pixels, your subsets&amp;#039; size is about 12 million, so the required memory would be 1.2G, far less than my computer&amp;#039;s memory,  so the questions are:&lt;br /&gt;&lt;br /&gt;1. why the snaphu was got deadlock?&lt;br /&gt;&lt;br /&gt;2. can these processing steps introduced here be used for TerraSar-X Spot light images?&lt;br /&gt;&lt;br /&gt;thanks a lot.</summary>
    <dc:creator>Jianwei Tao</dc:creator>
    <dc:date>2012-10-16T10:10:57Z</dc:date>
  </entry>
  <entry>
    <title>RE: Can't open CEOS</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=395930" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=395930</id>
    <updated>2012-10-12T18:31:46Z</updated>
    <published>2012-10-12T18:31:46Z</published>
    <summary type="html">The dataset is over Toronto. Most metadata is available except for some critical ones such as start and end times. What mission is it for?</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-10-12T18:31:46Z</dc:date>
  </entry>
  <entry>
    <title>Mosaicking Output??</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=389596" />
    <author>
      <name>Waqas A. Qazi</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=389596</id>
    <updated>2012-09-09T04:11:16Z</updated>
    <published>2012-09-09T04:11:16Z</published>
    <summary type="html">Hi,&lt;br /&gt;&lt;br /&gt;I&amp;#039;m trying to Mosaic two Envisat images (*.N1 format) in NEST. I don&amp;#039;t quite understand how to interpret the output. The input *.N1 images are uncalibrated magnitude/intensity images, and the mosaic output does not conform to the input range. I exporeted the mosaic to ENVI format, and the .hdr file says the mosaic band is &amp;#034;magnitude&amp;#034; but the range of values is really off, and does include -ve values, which is impossible.&lt;br /&gt;&lt;br /&gt;Does the NEST Mosaicking routine perform auto-calibration of data, or is there anything else going on? What is the default output data type of the Mosaicking process? Would really appreciate any help on this!!!&lt;br /&gt;&lt;br /&gt;Regards,&lt;br /&gt;Waqas.&lt;br /&gt;University of Colorado, Boulder.</summary>
    <dc:creator>Waqas A. Qazi</dc:creator>
    <dc:date>2012-09-09T04:11:16Z</dc:date>
  </entry>
  <entry>
    <title>RE: Envisat ASAR - Batch Processing - SubsetOp - Geo region</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=388784" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=388784</id>
    <updated>2012-08-30T14:05:02Z</updated>
    <published>2012-08-30T14:05:02Z</published>
    <summary type="html">Try creating a subset of only one product and then using that product as the master, coregister it with the other products.&lt;br /&gt;This will subset all other products according to the master while ensuring that they all represent the same area.&lt;br /&gt;With subsets alone based on the georeferencing of the product they may not cut out exactly the same area due to inaccuracies in the product geporeferencing.</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-08-30T14:05:02Z</dc:date>
  </entry>
  <entry>
    <title>ERS-2 SAR PRI calibration steps</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=384147" />
    <author>
      <name>William Joseph Blake</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=384147</id>
    <updated>2012-07-23T15:15:04Z</updated>
    <published>2012-07-23T15:15:04Z</published>
    <summary type="html">Dear Forum,&lt;br /&gt;&lt;br /&gt;I&amp;#039;d be grateful for some guidance on the correct processing steps for ERS SAR PRI products.&lt;br /&gt;&lt;br /&gt;I have 10 ERS-2 SAR PRI data products, all of the same track (393) and frame (4134).&lt;br /&gt;&lt;br /&gt;So far I have tried:&lt;br /&gt;&lt;br /&gt;Apply Orbit file&amp;gt;Calibrate&amp;gt;Speckle Filter&amp;gt;TCRD (no radiometric normalisation)&lt;br /&gt;Orbit files&amp;gt;Calibrate&amp;gt;Speckle filter&amp;gt;SARSim (no radiometric normalisation)&lt;br /&gt;Orbit files&amp;gt;RemoveAntPat&amp;gt;TCRD (radiometric normalisation)&lt;br /&gt;Orbit files&amp;gt;RemoveAntPat&amp;gt;SARSim (radiometric normalisation)&lt;br /&gt;&lt;br /&gt;This is a semi-arid dune system in the SW Kalahari region, there is a lot of noise, so I will be applying the multi-temporal speckle filter to a co-reg stack in the future. However, first of all I want to find the best calibration and orthorecitification method for ERS SAR PRI products.&lt;br /&gt;&lt;br /&gt;It is not particularly clear in the literature which method to follow for ERS SAR PRI products. All methods above seem to produce similar results as far as I can tell. Although the SARSim operation only seems to work when I use the Bi-Lin or Nearest Neighbour resampling method.&lt;br /&gt;&lt;br /&gt;Any advice would be very helpful. Thank you&lt;br /&gt;&lt;br /&gt;Will</summary>
    <dc:creator>William Joseph Blake</dc:creator>
    <dc:date>2012-07-23T15:15:04Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS2 import problem</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=383752" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=383752</id>
    <updated>2012-07-17T13:35:00Z</updated>
    <published>2012-07-17T13:35:00Z</published>
    <summary type="html">This is a level 0 raw product OP. NEST only works with level 1 and above. You need focussing software to process the level 0 to level 1. The best thing to do is to request the level 1 product from ESA. Level 1 is the distributed product for public use.</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-07-17T13:35:00Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS1 /2 and ENVISAT Image Mode Precision data</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=368613" />
    <author>
      <name>Luis Veci</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=368613</id>
    <updated>2012-04-12T19:38:07Z</updated>
    <published>2012-04-12T18:18:52Z</published>
    <summary type="html">Rachel, first of all, you shouldn&amp;#039;t generally put anything in front of Calibrate. Apply orbit file should be fine because it doesn&amp;#039;t modify the data but multilook will change the data and then the calibration may not be correct.&lt;br /&gt;&lt;br /&gt;Second, the SAR Simulation TC will simulate an image based on the DEM and then try to coregister this simulated image with a band from your input product. It may be that the simulated image and input band do not correlate easily. In this case it&amp;#039;s best to add more GCP points so that NEST could try to correlate the two image at more locations.&lt;br /&gt;&lt;br /&gt;Also, because the simulated image is based on the DEM, it&amp;#039;s only effective over terrain. If your data is a flat area with a city or airport, those features of course will not be present in the simulated image.</summary>
    <dc:creator>Luis Veci</dc:creator>
    <dc:date>2012-04-12T18:18:52Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS1 /2 and ENVISAT Image Mode Precision data</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=368587" />
    <author>
      <name>Rachel Joanne Carr</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=368587</id>
    <updated>2012-04-12T18:05:52Z</updated>
    <published>2012-04-12T18:05:52Z</published>
    <summary type="html">Hi Andrea,&lt;br /&gt;&lt;br /&gt;I have been processing my ERS 1 /2 imagery and I am having some issues with Terrain Correcting the data as a coregistered stack. I applied the following steps to my ERS and ENVISAT data: Apply orbit file (PRARE)&amp;gt; Multi look&amp;gt; Calibrate. I have then coregistered my ERS data with an ENVISAT image from the same track and the images match exactly. &lt;br /&gt;I have applied SarSim Terrain Correction and selected the appropriate ERS bands (i.e. the slave bands) in the dialogue box. Sometimes the Terrain Correction will run and produce a good result, but sometimes it will come back immediately and say that it could not find enough GCPS. I am not sure why the SarSim TC will not run on certain combinations of images: they are all from the same track and appear to have a similar coverage, so any ideas on the matter would be much appreciated. Alternatively, if I am missing an easier way to TC a set of co-registered images, then please do let me know.&lt;br /&gt;&lt;br /&gt;Many thanks,&lt;br /&gt;&lt;br /&gt;Rachel</summary>
    <dc:creator>Rachel Joanne Carr</dc:creator>
    <dc:date>2012-04-12T18:05:52Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS1 /2 and ENVISAT Image Mode Precision data</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=366221" />
    <author>
      <name>Rachel Joanne Carr</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=366221</id>
    <updated>2012-03-29T09:32:23Z</updated>
    <published>2012-03-29T09:32:23Z</published>
    <summary type="html">Following on from earlier post, I improved the geolocation accuracy of my ENIVSAT images to within a pixel by using a higher resolution DEM. &lt;br /&gt;&lt;br /&gt;Could I ask whether it is advisable to use images from different passes (i.e. ascending / descending) for change mapping purposes? My test images appear to match well, but it is difficult to assess as the images obviously look very different.</summary>
    <dc:creator>Rachel Joanne Carr</dc:creator>
    <dc:date>2012-03-29T09:32:23Z</dc:date>
  </entry>
  <entry>
    <title>RE: ERS1 /2 and ENVISAT Image Mode Precision data</title>
    <link rel="alternate" href="http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=364259" />
    <author>
      <name>Rachel Joanne Carr</name>
    </author>
    <id>http://nest.array.ca/c/message_boards/find_message?p_l_id=10348&amp;messageId=364259</id>
    <updated>2012-03-28T09:00:43Z</updated>
    <published>2012-03-28T09:00:43Z</published>
    <summary type="html">Hi Andrea / Luis,&lt;br /&gt;&lt;br /&gt;Many thanks for your help. In the end, I coregistered the ERS imagery to an ENVISAT image of the same path and then applied terrain correction, as suggested by Andrea, and got a good result. However, this did not work with the image that I posted above (even with a window of 1024, no GCPs were found), so I have sent the image to the ESA help desk and will post the response for reference.&lt;br /&gt;&lt;br /&gt;Having coregistered the ERS / ENVISAT imagery, could I ask what kind of geolocation accuracy I could expect from ENVISAT images from different tracks but with the same pass (in this case descending)? I have used the following steps: Apply orbit files (DORIS vor / por, dependant on date), Multilook (GR Sq Pixel, 3 range looks), Calibrate, Terrain correct (Range-Doppler, using a1 km resolution DEM). The study site is a glacial fjord, which varies in elevation from sea level to ~ 1500m across the scene. Using this method, I can get images from different tracks to correspond to within 100 – 200 m (3 – 5 pixels), by comparing common features such as rock outcrops. Does this amount of offset seem reasonable or is it possible to get better correspondence between images from different tracks? Similarly, could I ask what kind of offset you might expect to see between images from different paths?&lt;br /&gt;&lt;br /&gt;Many thanks,&lt;br /&gt;&lt;br /&gt;Rachel</summary>
    <dc:creator>Rachel Joanne Carr</dc:creator>
    <dc:date>2012-03-28T09:00:43Z</dc:date>
  </entry>
</feed>

