Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#4094 closed defect (worksforme)

Envisat MERIS: Incorrect count for "GeoTiePoints"

Reported by: knutfrode Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.8.0
Severity: normal Keywords:
Cc: knutfrode, antonio

Description (last modified by knutfrode)

The recent fix of ticket #4086 solved a problem with reading of GCPs for Envisat MERIS.

However, there is a remaining, related issue which seems to be limited to MER_RR2 (Level2 reduced resolution) data only (i.e. not a problem for Full Resolution (FR) or Reduced Resolution (RR) Level 1):

The GCPs are listed with gdal_info, but trying to convert to GeoTiff? an error is reported:

$ gdal_translate MER_RR__2PNPDK20110503_105421_000023063102_00109_47968_7916.N1 m1.tif
ERROR 1: TIFFFetchNormalTag:Incorrect count for "GeoTiePoints"; tag ignored

The output file is produced, but without GCPs. I have tested several files, and this error can also be reproduced with a sample file freely available here:

Converting to PNG instead, the GCPs are listed in the .aux.xml file, so the problem is probably specific to Tiff. I dont know whether it is a GDAL-problem or a libtiff problem?

This is tested on Mac OS X with both GDAL 1.8.0 and trunk (1.9dev)

Attachments (1)

av-config.log (136.2 KB) - added by antonio 9 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 9 years ago by knutfrode

Description: modified (diff)

comment:2 Changed 9 years ago by Even Rouault

This works fine for me on both trunk and the 1.8 branch, with internal libtiff or system libtiff (3.9.2). Could you be more specific on how you've built GDAL ?

comment:3 Changed 9 years ago by knutfrode

GDAL was installed simply with:

./configure --with-python
sudo make install

I recompiled now the trunk, and get the same error. It was also reproduced by a colleague on his Linux version.

In config.log I find however these lines:

configure:19546: checking for libtiff
configure:19551: checking for TIFFScanlineSize64 in -ltiff
configure:19576: gcc -o conftest    conftest.c -ltiff  -lz -lpthread -ldl  >&5
ld: library not found for -ltiff
collect2: ld returned 1 exit status
configure:19576: $? = 1
configure: failed program was:
| /* confdefs.h */

Perhaps this is relevant? I am sorry, but I am a novice on compiling C/C++

comment:4 Changed 9 years ago by Even Rouault

Errors in configure log are expected. This is the way it detects if features are available or not. Well, my deduction from this snippet is that it will build against internal libtiff due to no installed libtiff headers, which is not a problem. This could be confirmed by the summary of detected features that is displayed in the console at the end of running ./configure. But anyway I've no clue why it doesn't work for you... When you say "tested on Mac with GDAL 1.8", do you mean GDAL 1.8.0 or the latest svn checkout from the 1.8 branch ?

comment:5 Changed 9 years ago by knutfrode

Description: modified (diff)

You are right, config reports that the GDAL internal libtiff is used.

I have tested both the 1.8.0 release and the 1.9dev trunk (ticket description is updated).

comment:6 Changed 9 years ago by antonio

Sorry knutfrode, I can't reproduce the issue on my mac:

I'm going to attach my config.log

Is it possible that you have another version of libtiff around that makes some kind of interference with GDAL?

Changed 9 years ago by antonio

Attachment: av-config.log added

comment:7 Changed 9 years ago by Even Rouault

Resolution: worksforme
Status: newclosed

comment:8 Changed 8 years ago by knutfrode

A comment for the records:

I reproduced this on another machine and OS (Ubuntu 11.10, GDAL 1.10) with another input file format: self-made VRT files where I could configure the density of generated GCPs. The error message appears if the image has more than about 8000 GCPs. This number may probably be dependent on the version of libTiff.

Note: See TracTickets for help on using tickets.