I see <SourceFilename relativeToVRT="0">. I will try again after first changing that to<SourceFilename relativeToVRT="1">. I did not know about relativeToVRT. Thank you very much. Greg
On Jan 5, 2010, at 7:04 PM, Even Rouault wrote: > 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
