[gdal-dev] VRT file from NetCDF

Etienne Tourigny etourigny.dev at gmail.com
Tue Dec 13 11:50:04 EST 2011


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
<even.rouault at mines-paris.org> wrote:
> Selon Yves Jacolin <yjacolin at free.fr>:
>
>> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list