Ticket #4691 (closed defect: fixed)
GTiff::GetMetadata() can sometimes not contain any value for GDALMD_AREA_OR_POINT
| Reported by: | rouault | Owned by: | 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 ).
- The FIXME? comment is from myself, in http://trac.osgeo.org/gdal/changeset/19337 where I fixed something else and discovered that potential issue.
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.
