[Gdal-dev] vrt format and absolute/relative paths

[Vincent Schut]

I'm starting to use (and like!) the vrt format more and more. However, when I
thought I would use standard vrt files as templates for multiple directories
that contain the same kind of data (like spot vegetation data for multiple
dates), I found out that the vrt file loader uses the current working dir as
path prefix for the SourceFilename, which effectively keeps me from using
one .vrt file with relative filenames as SourceFilename and linking/copying
that into each directory. E.g. I would like to have a vrt file that has the
files 0001_B0.HDF, 0001_B2.HDF, 0001_B3.HDF and 0001_MIR.HDF as bands 1-4,
and than I put that vrt file in each of my Spot Vegetation directories and if
I then load one of the vrt files, it gives me the four HDF files from the
directory where the vrt file is located. However, the current behaviour is
different: it gives me the HDF files from the current directory. So if I
issue a gdalinfo command on a vrt file from a different directory:
***@lowresbox spotgetation/s10$ gdalinfo
Asian-Islands.20020601/spectral.vrt
gdal tries to load the referenced raster sources from the current directory
(spotvegetation/s10/), and not from the local directory of the vrt file
(spotvegetation/s10/Asian-Islands.20020601/). So in this example I would get
an error, as there are no Spot Vegetation raster files in
spotvegetation/s10/.

Is this behaviour intended?
If not, if would greatly help me if it could be changed so that gdal always
uses the home directory of the current vrt file to look for the vrt raster
source files.

Thanks,

[Vincent Schut]

Adding to myself:

note that also gdal_translate creates vrt files with relative filenames for
the rastersources. When trying to load the created vrt file using a program
that has been started from a different working dir, loading will give an
error because gdal looks for the rastersources in the wrong dir. Or, even
worse, you will not get an error but the wrong raster data if raster files
with the same name as those mentioned in the vrt file are also present in the
cwd...

Post by Vincent Schut
I'm starting to use (and like!) the vrt format more and more. However, when
I thought I would use standard vrt files as templates for multiple
directories that contain the same kind of data (like spot vegetation data
for multiple dates), I found out that the vrt file loader uses the current
working dir as path prefix for the SourceFilename, which effectively keeps
me from using one .vrt file with relative filenames as SourceFilename and
linking/copying that into each directory. E.g. I would like to have a vrt
file that has the files 0001_B0.HDF, 0001_B2.HDF, 0001_B3.HDF and
0001_MIR.HDF as bands 1-4, and than I put that vrt file in each of my Spot
Vegetation directories and if I then load one of the vrt files, it gives me
the four HDF files from the directory where the vrt file is located.
However, the current behaviour is different: it gives me the HDF files from
the current directory. So if I issue a gdalinfo command on a vrt file from
Asian-Islands.20020601/spectral.vrt
gdal tries to load the referenced raster sources from the current directory
(spotvegetation/s10/), and not from the local directory of the vrt file
(spotvegetation/s10/Asian-Islands.20020601/). So in this example I would
get an error, as there are no Spot Vegetation raster files in
spotvegetation/s10/.
Is this behaviour intended?
If not, if would greatly help me if it could be changed so that gdal always
uses the home directory of the current vrt file to look for the vrt raster
source files.
Thanks,

[Frank Warmerdam]

Post by Vincent Schut
Is this behaviour intended?
If not, if would greatly help me if it could be changed so that gdal always
uses the home directory of the current vrt file to look for the vrt raster
source files.

Vincent,

I have modified the VRT code in CVS so that it will check for a relativeToVRT
attribute on the SourceFilename element. If it is set to a non-zero value then
the SourceFilename will be treated relative to the virtual file. For example:

<VRTDataset rasterXSize="512" rasterYSize="512">
<VRTRasterBand dataType="Byte" band="1">
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">utm.tif</SourceFilename>
<SourceBand>1</SourceBand>
<SrcRect xOff="0" yOff="0" xSize="512" ySize="512"/>
<DstRect xOff="0" yOff="0" xSize="512" ySize="512"/>
</SimpleSource>
</VRTRasterBand>
</VRTDataset>

Currently CreateCopy() does not attempt to set this, and relativize the path
though it might at some point in the future.

In general, even when doing a gdal_translate the .vrt may be put somewhere
completely unrelated to the actual files in which case it is hard to make
the SourceFilename relative to the .vrt. While it has some significant
problems the code (for the time being) will just literally place whatever
filename you give it for the the input file into the SourceFilename element.

However, with a minor hand edit to your .vrt files you should now be able to
use them as desired.

Best regards,

[Vincent Schut]

Frank,

thank you very much for this elegant solution.

Regards,
Vincent Schut.

Post by Frank Warmerdam

Post by Vincent Schut
Is this behaviour intended?
If not, if would greatly help me if it could be changed so that gdal
always uses the home directory of the current vrt file to look for the
vrt raster source files.

Vincent,
I have modified the VRT code in CVS so that it will check for a
relativeToVRT attribute on the SourceFilename element. If it is set to a
non-zero value then the SourceFilename will be treated relative to the
<VRTDataset rasterXSize="512" rasterYSize="512">
<VRTRasterBand dataType="Byte" band="1">
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">utm.tif</SourceFilename>
<SourceBand>1</SourceBand>
<SrcRect xOff="0" yOff="0" xSize="512" ySize="512"/>
<DstRect xOff="0" yOff="0" xSize="512" ySize="512"/>
</SimpleSource>
</VRTRasterBand>
</VRTDataset>
Currently CreateCopy() does not attempt to set this, and relativize the
path though it might at some point in the future.
In general, even when doing a gdal_translate the .vrt may be put somewhere
completely unrelated to the actual files in which case it is hard to make
the SourceFilename relative to the .vrt. While it has some significant
problems the code (for the time being) will just literally place whatever
filename you give it for the the input file into the SourceFilename element.
However, with a minor hand edit to your .vrt files you should now be able
to use them as desired.
Best regards,

[Fu Chen]

Hi!
I test one of my old program. But find GDAL120b has some problems in parsing the FAST format.

#include "gdal_priv.h"
#include "cpl_conv.h"

int main ( int argc, char ** argv)
{
GDALAllRegister();
GDALDataset * poDataset= (GDALDataset *) GDALOpen( "h:\\chinagisdata\\landsatdata\\L71118038_03820020111_HPN.FST", GA_ReadOnly );
const char * sDriverDesc = poDataset->GetProjectionRef();
printf(sDriverDesc);
}

gdal119 output:

PROJCS["unnamed",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.
257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","632
6"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519
9433,AUTHORITY["EPSG","9108"]],AXIS["Lat",NORTH],AXIS["Long",EAST],AUTHORITY["EP
SG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0]
,PARAMETER["central_meridian",123],PARAMETER["scale_factor",1],PARAMETER["false_
easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

gdal120b output:

PROJCS["unnamed",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.
257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","632
6"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519
9433,AUTHORITY["EPSG","9108"]],AXIS["Lat",NORTH],AXIS["Long",EAST],AUTHORITY["EP
SG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0]
,PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_ea
sting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

You can see in central_meridian false_easting are not correctly interpreted in 120b. What's change in the new version on the FAST format?

any idea?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: L71118038_03820020111_HPN.FST
Type: application/octet-stream
Size: 4608 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040316/7119dcb4/L71118038_03820020111_HPN.obj

[Andrey Kiselev]

Post by Fu Chen
I test one of my old program. But find GDAL120b has some problems in
parsing the FAST format.
You can see in central_meridian false_easting are not correctly
interpreted in 120b. What's change in the new version on the FAST
format?

Well, there was many changes in the FAST driver to support the wide
range of broken mind data distributors. I have found your problem and it
should be fixed in the CVS now.

Thank you for report,
Andrey