Opened 13 years ago

Closed 12 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, Even 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 by warmerdam, 13 years ago

Cc: chaitanya added
Component: defaultGDAL_Raster


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

comment:2 by chaitanya, 13 years ago


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

comment:3 by chaitanya, 13 years ago

Cc: warmerdam added; chaitanya removed
Owner: changed from warmerdam to chaitanya
Status: newassigned

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

comment:4 by knutfrode, 13 years ago

Severity: normalcritical

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 by knutfrode, 13 years ago

Priority: normalhigh

comment:6 by knutfrode, 12 years ago

Cc: Even Rouault added

comment:7 by Even Rouault, 12 years ago

(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 by antonio, 12 years ago

Cc: antonio added

comment:9 by knutfrode, 12 years ago

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 by warmerdam, 12 years ago

Milestone: 1.8.1
Resolution: fixed
Status: assignedclosed

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.