[Gdal-dev] VRT format Schema

[Frank Warmerdam]

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,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org