[gdal-dev] Passing RAT between drivers, including VRT

[Even Rouault]

Le jeudi 15 août 2013 18:53:46, Ivan Lucena a écrit :
> Hi folks,
> 
> I might be wrong, but it looks like the VRT driver is not supporting RAT at
> this moment (TRUNK).
> 
> Is that correct?

Hi Ivan,

yes, correct. See http://trac.osgeo.org/gdal/ticket/4903 where there's a patch 
pending for this support.

> 
> A simple way to test it is by "gdal_translating" that file "i8u_c_i.img"
> from autotest to VRT:
> 
> $ gdal_translate -of vrt i8u_c_i.img vrt_i8u_c_i.vrt
> $ gdalinfo vrt_i8u_c_i.vrt -noct
> 
> The RAT is not there.
> 
> That wouldn't be a big problem by itself, the real problem is that
> gdal_translate uses an internal VRT to support several options. And I am
> trying to fix that ticket: http://trac.osgeo.org/gdal/ticket/5200 and I
> noticed that when I use *-a_nodata* the GetDefaultRAT() it returns null.
> 
> Drivers that implement *file based* GDALPamDataset doesn't seems to have
> that problem because they don't need to call GetDefaultRAT(). Examples:
> 
> $ gdal_translate -of gtiif i8u_c_i.img gtiff_i8u_c_i.tif -a_nodata 0
> $ gdal_translate -of gtiif i8u_c_i.img gtiff_i8u_c_i.tif
> 
> The RAT is transferred to the geotiff file in both instances.

That's surprising !, and even not what I observe in my test. The RAT is 
transfered in the simple gdal_translate case (since the IMG dataset is 
directly passed as the source dataset so GetDefaultRAT() != NULL), but not in 
the -a_nodata 0 case since the source dataset is a VRT one, without RAT 
support.

> 
> Is that something we would like to get fix in VRT?

Likely, the patches in http://trac.osgeo.org/gdal/ticket/4903 would need to be 
rebased on trunk since RFC 40 has been implemented.

> 
> Best regards,
> 
> Ivan

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html