Yves, I tried the vrt and netcdf file you supplied and I got the same problem if I started QGIS from another directory (than where the VRT file is stored), but it worked if I was in the same directory.
However, gdalinfo -stats tmp4.vrt worked fine from another directory... I can't understand why gdalinfo succeed where QGIS does not, they are using the same driver! Even's suggestion does make sense: use the full path in VRT files, especially if using mapserver or QGIS. Etienne On Tue, Dec 13, 2011 at 2:37 PM, Even Rouault <[email protected]> wrote: > Selon Yves Jacolin <[email protected]>: > >> Hello, >> >> Etienne asked some question offlist so I investigate. >> >> gdal create relatif path by default (I don't see a flag to change this). >> MapServer and QGIS don't like this. > > MapServer and QGIS don't even know the content of the VRT, so the problem is > more complex than that. > > If you pass a relative path to gdalbuildvrt or gdal_translate -of VRT, a > relative path will be written. In which case the VRT driver should be able to > recompute the full path given the location of the .vrt. > On the contrary, if you pass an absolute path, it will be store as absolute. > > The issue here is likely with netCDF subdatasets, where the connexion string > is > not a file, but something like "netCDF:xxxx:a_filename", that the VRT driver > cannot interpret. In that case, the resolution of relative filenames will not > work. So I'd suggest you to use "netCDF:xxx:full_filename" to avoid those > issues. Or you must be sure that the current directory of MapServer and QGIS > is > the directory of the .VRT, but you cannot always guarantee this. > >> >> After changing relatif path to absolute path both are working correctly. >> >> Thanks, > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
