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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
