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