#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 ).
- 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.
Change History (6)
comment:1 by , 12 years ago
Milestone: | → 2.0.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:2 by , 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 , 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.
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