[gdal-dev] read a catalog is slower then directly the raster ?

[Even Rouault]

> I try to create the overview, but it is really sloow .
> After 1hours is to 0%.

Well, given the size of the tile whose XML description you gave, I'm not that
surprised it would be very long, if you have lots of similar ones in your VRT.
But after one hour, this is indeed not a good sign that the progress bar stays
at 0%. There is a known performance problem when accessing ECW with some access
patterns ( http://trac.osgeo.org/gdal/ticket/3454 ). Perhaps you are running
into it.

>
> I will try with a selection of few rasters.
>
>
> >
> > > I guess this is a good reason to explain because it is so slow when in
> > the
> > > catalog there and many hundred of rasters.
> > >
> > > Unfortunately I don't find any option in gdalbuildvrt to add the
> > extension
> > > of every raster in the catalog.
> >
> > There's none : the above information that is generated by default is
> > sufficient.
> >
> >
> Sorry Roualt,
> the catalog give the start point and the number of pixel , but miss the
> size in meters or "unit of map" of every pixel so for me was not possible
> to detect the bbox of every raster.

Well, I've spent several dozains of hours hacking in the VRT driver over the
last few years to be pretty sure that there is everything needed in the VRT
generated by gdalbuildvrt to avoid opening each tile when doing windowed
request. If you look at the XML extract you mentionned, we have the information
on the size and blocking of the tile (SourceProperties element), we know which
window of the tile to extract (SrcRect) and we know where it must be located in
the VRT mosaic and at which size (DstRect). The last one (DstRect) is sufficient
to know if a tile is needed to satisfy a RasterIO request on the VRT. There's no
need to known the size in meters of pixels of each tile.

> Perhaps in the overview there is the missing information ?

No, having an overview will just avoid opening each tile.

>
> >Best regards,
> >
> >Even
>
> Thx,
> Andrea.
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>