Benoît, yes this XSD idea apparently did not go further than this dicussion. The best description of the VRT format is to be found on http://www.gdal.org/gdal_vrttut.html
You can try gdal_translate -of VRT or gdalbuildvrt to have examples of valid VRT files. For your use case, "gdalbuildvrt -separate out.vrt in1.tif in2.tif in3.tif" should generate what you expect. Best regards, Even > Hi list ! > > I need to merge three tif files, each one having a single Float32 band. > I want each file to use a separated band of the final tif. > > I think the best way to do this is to use the VRT driver. > I would have liked to not use the C# binding or the native C++ library. > I would prefer to create a file on the disk using C# serialization. > > I am so searching for the schema of the VRT format and I've found this > quite old thread. I saw the XSD in one of the messages of the topic. Is it > correct ? It is mentionned too that the XSD should be in the CVS/SVN in > gdal/frmts/vrt but I've not found it, I assume the idea has been > abandonned. > > I am also interested in any other suggestion ! ^^ > > Thanks in advance. > > Regards, > Benoit Andrieu > > Antoine Hue wrote: > >>>/ There are still a few dark zones and area to improves: > > />>>/ - ComplexSource and AverageSource need a complete definition > />/ Any information about these sources? They do not appear in the VRT tut > />/ and I did not get there purpose/functioning. > />>>/ - Better definition of the subClass property of the VRTRasterBand > />>>/ needed. > />>/ > />>/ What did you need to know? It seems that values include > />>/ "VRTWarpedDataset", > />>/ "VRTDerivedRasterBand" and "VRTRawRasterBand". > />/ OK, I will add this. What is the impact this parameter on the VRT > />/ processing? > / > Antoine, > > It determines what elements are legal on the VRTRasterBand and > internally it tells GDAL which particular class to instantiate. > This "subClass" attribute approach does not really lend itself to > describing the grammar with XML schema as far as I know. > > >>>/ - An explicit definition of the raw raster source (to go with > > />>>/ SimpleSource, KernelFilteredSource,..) would improve homogeneity. > />>/ > />>/ I'm not sure what you mean. Isn't the ".vrt Descriptions for Raw > Files" />>/ on the gdal_vrttut.html page appropriate? > / > > > >/ For example, Simple source are described in the<SimpleSource> tag. > > />/ However, there is no<RawRasterSource> tag but a set of tags specific > />/ to the raw raster band (<VRTRasterBand subClass="VRTRawRasterBand">) > / > That is correct, there is no RawRasterSource or equivelent. Raw, warped > and "derived" data can only be implemented as complete bands, not sources > on a sourced band. > > >/ This actually appears in the schema: > > />/ > />/ <!-- Raster Band --> > />/ <xsd:complexType name="vrt_raster_band_t"> > />/ .... > />/ <xsd:choice maxOccurs="unbounded"> > />/ <xsd:element name="SimpleSource" type="simple_source_t" /> > />/ <xsd:element name="KernelFilteredSource" > />/ type="kernel_source_t" /> > />/ <xsd:element name="ComplexSource" /> <!-- Need refinement > --> />/ <xsd:element name="AveragedSource" /> <!-- Need > refinement --> />/ <xsd:sequence> > />/ <!-- Raw source --> > />/ <xsd:element name="SourceFilename" > />/ type="source_file_name_t"/> > />/ <xsd:element name="ImageOffset" > />/ type="xsd:nonNegativeInteger" /> > />/ <xsd:element name="PixelOffset" > />/ type="xsd:nonNegativeInteger" /> > />/ <xsd:element name="LineOffset" > />/ type="xsd:nonNegativeInteger" /> > />/ <xsd:element name="ByteOrder" type="byte_order_t" /> > />/ </xsd:sequence> > />/ </xsd:choice>... > />/ </xsd:complexType> > />/ > />/ One more question about it, the extract above allows mixed type > sources />/ within a raster band. Is this correct? > / > A "sourced" raster band (the default kind of VRTRasterBand) can have > a mixture of different sources. > > >>/ Were you thinking of the .xsd file as being primarily useful for > > />>/ automated validation of .vrt files? As educational? > />/ Why not both? > />/ Schema is more extensive than the tutorial and more readable than C++. > />/ It may also simplify C++ by checking validity of the VRT in place of > the />/ C++. > / > As I mention, I think I have approached the .vrt files in a way that is > not conveniently expressed in XML Schema and I would contend that the > schema files are not all that readable as a description. > > >/ Schema may also make it possible to version VRT grammar and enable > > />/ evolution of the format. > / > Well, keep in mind that the code is using a schema supporting parser > of any kind, so the .xsd files aren't systematically useful to GDAL > itself. As for versioning, I anticipate handling this in an adhoc > fashion, primarily by just extending the format rather than changing > existing items. > > Best regards, _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev