Opened 6 years ago

Closed 6 years ago

#3709 closed defect (fixed)

Georeference problem with Envisat Images

Reported by: timatkinson Owned by: chaitanya
Priority: high Milestone: 1.8.1
Component: GDAL_Raster Version: unspecified
Severity: critical Keywords: Envisat GeoReference
Cc: warmerdam, rouault, antonio


Gdal 1.6.2 (as featured in Fedora 13) and gdal 1.7.2 (as featured in Ubuntu 10.4) both have a problem with Georeference of Envisat Images

It appears they are reading both the Geolocation grid ADS (correct) and the Doppler Centroid Grid (incorrect) as GCPs.

The numbers in the grids are similar but actually different and hence you get two sets of ground coordinates per one GCP Line,Column

Run the command line below (*.N1 any envisat file will do)

gdalinfo *.N1 | grep \(0.5,0.5\) and you'll instantly see the problem

Change History (10)

comment:1 Changed 6 years ago by warmerdam

  • Cc chaitanya added
  • Component changed from default to GDAL_Raster


Could you see if you can find envisat data to replicate this? It may be hard to find some.

comment:2 Changed 6 years ago by chaitanya


Can you provide some sample data? You can email it to me ( * if you want it to be confidential.

comment:3 Changed 6 years ago by chaitanya

  • Cc warmerdam added; chaitanya removed
  • Owner changed from warmerdam to chaitanya
  • Status changed from new to assigned

I was able to reproduce the problem with a sample dataset from Anders Berg. I'm working on this.

comment:4 Changed 6 years ago by knutfrode

  • Severity changed from normal to critical

For Envisat ASAR, the mistake is that the parameter "line_num" of Geolocation Grid is used as the Y-coordinate (tested with gdalinfo v1.7). In the ESA documentation for ASAR Level 1 products, there is a warning that "line_num" is the line number relative to the "granule within the slice", and not of the image itself.

Instead, the Y-coordinate should be calculated as a cumulative sum from the "num_lines" parameter: [1 cumsum(num_lines)] in Matlab-notation.

Note that Ticket #3160 refers to the same issue. A patch is posted there, but I am not sure if that solves the issue.

I propose to increase the priority of this ticket, as Envisat is one of the major satellites, and the data are not very useful without georeferencing.

comment:5 Changed 6 years ago by knutfrode

  • Priority changed from normal to high

comment:6 Changed 6 years ago by knutfrode

  • Cc rouault added

comment:7 Changed 6 years ago by rouault

(I see you've cc'ed me. Just to mention I have no particular competence/interest on this file format and don't intend to take any particular action on this)

comment:8 Changed 6 years ago by antonio

  • Cc antonio added

comment:9 Changed 6 years ago by knutfrode

I have recompiled GDAL with the patch which was posted by Antonio in Ticket #3160, and can confirm that it solves the problem.

Are there any developers who would like to apply this patch to the official repository, and then close these two tickets (#3160 and #3709)?

comment:10 Changed 6 years ago by warmerdam

  • Milestone set to 1.8.1
  • Resolution set to fixed
  • Status changed from assigned to closed

Patch applied in trunk (r22289) and 1.8 branch (r22290). Tested by a user in #3709, but not actually tested by me.

Note: See TracTickets for help on using tickets.