Le mardi 01 février 2011 22:57:10, Ricardo Filipe Soares Garcia da a écrit : > Hi Even, list > > Since I don't have a chance to test gdal 1.8.0 at my machine, I > decided to apply an (ugly) hack to alter the VRT file after it is > created, changing all the 'relativeToVRT' values to '0'. It is working > fine.
I imagine ubuntugis will be updated at some point to use GDAL 1.8.0 > > About my other question: > > - Is it possible to use derived bands via python bindings? I guess > I'll have to write a pixel function and somehow register it with > gdal... I don't think it is possible via python bindings. You probably need to use C++ for that. > > > My HDF5 files have a scaling factor that I'd like to correct through > the VRT. I guess this is one of the points in using derived bands. If > it can't be done with a derived band, is there other option? Yes, instead of adding a <SimpleSource> use a <ComplexSource> than is an extension of <SimpleSource> that can have a <ScaleRatio> sub element. See http://www.gdal.org/gdal_vrttut.html > > Thanks > > > On Tue, Feb 1, 2011 at 6:50 PM, Even Rouault > > <even.roua...@mines-paris.org> wrote: > > Ricardo, > > > > Basically the XML you pass with SetMetadataItem() is deserialized and > > serialized again, but the relativeToVRT element isn't part of the > > internal model of the VRT driver and is "recomputed" at serialization > > time, so this explains why it can change behind your back. > > > > I think however that this has been fixed in GDAL 1.8.0 in > > http://trac.osgeo.org/gdal/changeset/20939 > > > > Best regards, > > > > Even > > > > Le mardi 01 février 2011 02:27:36, Ricardo Filipe Soares Garcia da a écrit : > >> Hello list > >> I am trying to create a .VRT file to mosaic a bunch of HDF5 files. It > >> is starting to work, except for the fact that I can't seem to set the > >> relativeToVRT attribute of the SourceFilename tag to "0". > >> > >> I've been adapting the online vrt tutorial[1] from C++ to Python. The > >> tutorial says that relativeToVRT will default to "0", but I'm getting > >> the exact opposite. It is defaulting to "1", and even if I try to set > >> it to "0" explicitly when using the SetMetadataItem method, it will > >> still be saved as a "1". I have included an excerpt of the code at the > >> end of this message. I'll post the rest of it if it is relevant. > >> > >> After saving the file, I can open a text editor and replace all the > >> "1" with "0" and this fixes it, allowing me to get the desired > >> visualization (on QGIS). > >> > >> Am I doing something wrong here? Or is this possibly a bug? I'm using > >> gdal 1.7.3, as available on the ubuntugis-unstable repository. > >> > >> > >> Another question: is it possible to use derived bands via python > >> bindings? I guess I'll have to write a pixel function and somehow > >> register it with gdal... > >> > >> [1] - http://www.gdal.org/gdal_vrttut.html > >> > >> [2] - python code follows: > >> > >> > >> def get_xml_source(fileName, dataSet, xSize, ySize, dType, blockX, > >> blockY, sXOff, sYOff, sXSize, sYSize, dXOff, > >> dYOff, dXSize, dYSize, relToVRT=0, band=1): > >> template = """ > >> <SimpleSource> > >> <SourceFilename relativeToVRT='%i'>HDF5:%s://%s</SourceFilename> > >> <SourceBand>%i</SourceBand> > >> <SourceProperties RasterXSize='%i' RasterYSize='%i' DataType='%s' > >> BlockXSize='%i' BlockYSize='%i' /> > >> <SrcRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' /> > >> <DstRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' /> > >> </SimpleSource> > >> """ > >> return template % (relToVRT, fileName, dataSet, band, xSize, ySize, > >> dType, blockX, blockY, sXOff, sYOff, sXSize, > >> sYSize, dXOff, dYOff, dXSize, dYSize) > >> > >> .... somewhere down the code... > >> > >> xmlSource = get_xml_source(lit, dataSet, xResolution, yResolution, > >> "Int16", blockXSize, blockYSize, 0, > >> 0, xResolution, yResolution, xOff, yOff, xResolution, yResolution) > >> outBand.SetMetadataItem("teste", xmlSource, "new_vrt_sources") _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev