Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4691 closed defect (fixed)

GTiff::GetMetadata() can sometimes not contain any value for GDALMD_AREA_OR_POINT

Reported by: Even Rouault Owned by: Even Rouault
Priority: normal Milestone: 1.10.0
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc: etourigny

Description

http://lists.osgeo.org/pipermail/gdal-dev/2012-May/033003.html

When using a driver's CreateCopy function to copy a source dataset in
GTiff format, It seems that  the  AREA_OR_POINT metadata is not
initialized.

This is seemingly  for performance reasons as shown in the code below.
 However, it has the unwanted side-effect that the AREA_OR_POINT
metadata item is not copied over in most (all?) drivers.

This may be worth fixing and certainly worth being documented somewhere.
Are there other drivers which have the same behaviour?

char **GTiffDataset::GetMetadata( const char * pszDomain )
{
[...]
    /* FIXME ? Should we call LookForProjection() to load
GDALMD_AREA_OR_POINT ? */
    /* This can impact performances */

    return oGTiffMDMD.GetMetadata( pszDomain );
}

My analysis :

I've done a bit of archeology :

  • GDALMD_AREA_OR_POINT is only set when the projection information is read, which is now defered in LookForProjection(), since

http://trac.osgeo.org/gdal/changeset/16823 ( http://trac.osgeo.org/gdal/ticket/2957 for the context ).

If the CreateCopy() implementation calls GetProjectionRef() or GetGeoTransform() before calling GetMetadata(), then GDALMD_AREA_OR_POINT shall be initialized.

GDALDriver::DefaultCreateCopy() calls them in that order (by chance), but apparently you are running into a case where a driver with a specialized CreateCopy() implementation does not do things in that order, but obviously, we cannot blame another driver for not doing the calls in the """"right"""" order.... And I'd bet that you this might be the netCDF driver, since its CreateCopy() implementation seems - at first sight - to call GetMetadata() before GetProjectionRef() ;-)

Solution :

Have a light version of LookForProjection() that only loads the GTRasterTypeGeoKey geotiff key. At first, I thought this wasn't possible without building the full projection string (which can be costly), but actually it is possible since GTIFGetOGISDefn() doesn't interfere with that key.

Change History (6)

comment:1 by Even Rouault, 12 years ago

Milestone: 2.0.0
Resolution: fixed
Status: newclosed

r24522 /trunk/gdal/frmts/gtiff/geotiff.cpp: GTiff: make sure that GetMetadata() initializes the value of GDALMD_AREA_OR_POINT item, if not already done (#4691

comment:2 by etourigny, 12 years ago

Even, thanks for such a quick response.

This issue was indeed with the netcdf CreateCopy() function, it *might* happen in other drivers also? I don't think that the doc for creating new drivers recommends this order of things.

For the netcdf driver in 1.9 - I will just get the WKT before getting the metadata, this shouldn't change anything really.

comment:3 by Even Rouault, 12 years ago

Yes, other drivers might exhibit the same issue. The doc does not mention any order, because really that behaviour is a side-effect of an optimization, that has never been really intended.

comment:4 by etourigny, 12 years ago

I don't think it's a big deal anyway.

Fixed the netcdf driver in 1.9 (r24526) and trunk (r24527) - just in case

comment:5 by Even Rouault, 12 years ago

Just for clarity : r24527 (the trunk commit) was unnecessary due to the fix done in r24522, but that won't hurt.

comment:6 by etourigny, 12 years ago

yes, that's why I wrote 'just in case'. thanks

Note: See TracTickets for help on using tickets.