[gdal-dev] gdalbuildvrt absolute path work, relative paths do not work

Greg Coats gregcoats at mac.com
Tue Jan 5 20:00:08 EST 2010


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[&quot;NAD27 / UTM zone 11N&quot;,GEOGCS[&quot;NAD27&quot;,DATUM[&q
> uot;North_American_Datum_1927&quot;,SPHEROID[&quot;Clarke 1866&quot;,6378206.4,2
> 94.9786982138982,AUTHORITY[&quot;EPSG&quot;,&quot;7008&quot;]],AUTHORITY[&quot;E
> PSG&quot;,&quot;6267&quot;]],PRIMEM[&quot;Greenwich&quot;,0],UNIT[&quot;degree&q
> uot;,0.0174532925199433],AUTHORITY[&quot;EPSG&quot;,&quot;4267&quot;]],PROJECTIO
> N[&quot;Transverse_Mercator&quot;],PARAMETER[&quot;latitude_of_origin&quot;,0],P
> ARAMETER[&quot;central_meridian&quot;,-117],PARAMETER[&quot;scale_factor&quot;,0
> .9996],PARAMETER[&quot;false_easting&quot;,500000],PARAMETER[&quot;false_northin
> g&quot;,0],UNIT[&quot;metre&quot;,1,AUTHORITY[&quot;EPSG&quot;,&quot;9001&quot;]
> ],AUTHORITY[&quot;EPSG&quot;,&quot;26711&quot;]]</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
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 



More information about the gdal-dev mailing list