Greg,
I doubt this is QGIS related, because QGIS has no idea of what is inside
the VRT itself ! So you should be able to reproduce only with gdal
utilities. A gdalinfo -checksum on the VRT would emit an error message
and output 0 as the checksum value if he cannot find the source rasters.
You should check that the 'relativeToVRT' attribute in your VRT is set
to 1. I strongly suspect the failure is due to 'relativeToVRT' being set
to 0 in your case, thus GDAL interprets the path as an absolute path.
This might happen in some situations where GDAL cannot figure out how
the VRT and the source rasters path relate to each other. Read carefully
http://lists.osgeo.org/pipermail/gdal-dev/2009-October/022358.html for a
detailed explanation. I suspect you just hit case number 1) when
building your VRT, which has been fixed in GDAL 1.7.0dev
Otherwise check your tree structure and that the VRT is correctly
located for ../../GeoJPEG2000/18stj/18stj715050.jp2 being valid.
I've tested the following simple VRT (let's call it 'byte.vrt') and
provided that the hierarchy is like :
/a/b/c/byte.tif
/a/b/c/subdirectory/byte.vrt
from any working directory, gdalinfo -checksum
/a/b/c/subdirectory/byte.vrt --> works
from /a/b/c/, gdalinfo -checksum subdirectory/byte.vrt -> works
from /a/b/c/subdirectory, gdalinfo -checksum byte.vrt -> works
<VRTDataset rasterXSize="20" rasterYSize="20">
<SRS>PROJCS["NAD27 / UTM zone
11N",GEOGCS["NAD27",DATUM[&q
uot;North_American_Datum_1927",SPHEROID["Clarke
1866",6378206.4,2
94.9786982138982,AUTHORITY["EPSG","7008"]],AUTHORITY["E
PSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree&q
uot;,0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTIO
N["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],P
ARAMETER["central_meridian",-117],PARAMETER["scale_factor",0
.9996],PARAMETER["false_easting",500000],PARAMETER["false_northin
g",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]
],AUTHORITY["EPSG","26711"]]</SRS>
<GeoTransform> 4.4072000000000000e+005, 6.0000000000000000e+001,
0.00000000000
00000e+000, 3.7513200000000000e+006,
0.0000000000000000e+000,-6.0000000000000000
e+001</GeoTransform>
<VRTRasterBand dataType="Byte" band="1">
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">../byte.tif</SourceFilename>
<SourceBand>1</SourceBand>
<SourceProperties RasterXSize="20" RasterYSize="20"
DataType="Byte" BlockX
Size="20" BlockYSize="20"/>
<SrcRect xOff="0" yOff="0" xSize="20" ySize="20"/>
<DstRect xOff="0" yOff="0" xSize="20" ySize="20"/>
</SimpleSource>
</VRTRasterBand>
</VRTDataset>
Greg Coats a écrit :
I am running the 31 Dec 2009, Qgis version 1.4.0 Enceladus, code
revision 12644, compiled for Mac OS X 10.6, downloaded
from http://www.kyngchaos.com <http://www.kyngchaos.com/>
The problem I am having is that while files created by GDAL 1.6.3,
released 2009/11/19 gdalbuildvrt that include in the .vrt file
absolute paths work fine
/Users/gregcoats/gis/dcuatest/GeoJPEG2000/18stj/18stj715050.jp2
when relative paths are used in the .vrt file, then the images are not
found, and instead all black is drawn
../../GeoJPEG2000/18stj/18stj715050.jp2
Qgis accepts relative paths for images not in the gdalbuildvrt .vrt file.
I am seeking a work around solution for this problem.
Greg
------------------------------------------------------------------------
_______________________________________________
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
