Opened 13 years ago

Last modified 11 years ago

#4094 closed defect

Envisat MERIS: Incorrect count for "GeoTiePoints" — at Version 5

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:
http://www.brockmann-consult.de/beam/data/products/MERIS/MER_RR__2PNRAL20100429_160201_000003102089_00040_42679_0001.zip

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)

Change History (5)

comment:1 by knutfrode, 13 years ago

Description: modified (diff)

comment:2 by Even Rouault, 13 years ago

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

GDAL was installed simply with:

./configure --with-python
make
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 by Even Rouault, 13 years ago

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

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).

Note: See TracTickets for help on using tickets.