[gdal-dev] creating .VRT files with the python bindings

[Ricardo Filipe Soares Garcia da]

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.

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...


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?

Thanks


On Tue, Feb 1, 2011 at 6:50 PM, Even Rouault
<even.rouault at 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")
>



-- 
___________________________ ___ __
Ricardo Garcia Silva