[gdal-dev] VRT file from NetCDF

[Even Rouault]

Selon Yves Jacolin <yjacolin at free.fr>:

> Hello,
>
> Sorry to come again to this thread :)
>
> It seems that when using relatif file for NETCDF for instance, MapServer
> won't
> work correclty, see Even comment below.
>
> Is it a bug from GDAL? Do I need to open a ticket about this?

I don't see an easy fix to improve that. That would require some cooperation
with the driver to return the filename from the connection string and to reform
a new connection string with the full filename. IMHO not worth the effort, but
perhaps worth documenting it for the moment.

>
> Y.
> >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,
>
> Y.
> --
> Yves Jacolin
>
> http://yjacolin.gloobe.org
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>