Thanks Duarte and Etienne,<br><br>That is very useful information.<br>I wouldn't thought about it reading just the documentation.<br clear="all"><br><p style="margin-bottom:0cm" lang="nl-NL">Thanks,<br></p>

<br>
Paul <br>
<br><br><div class="gmail_quote">2012/7/12 Etienne Tourigny <span dir="ltr"><<a href="mailto:etourigny.dev@gmail.com" target="_blank">etourigny.dev@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

You should generate the stats for every file, as you will probably get<br>
incorrect results with your method<br>
<br>
for f in *.tif; do gdalinfo -stats $f ; done<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jul 12, 2012 at 9:03 AM, Duarte Carreira <<a href="mailto:DCarreira@edia.pt">DCarreira@edia.pt</a>> wrote:<br>
> Hi Paul.<br>
><br>
><br>
><br>
> I had to build a big vrt. The one trick that got it loading very fast into<br>
> qgis was adding statistics to each rasterband:<br>
><br>
>   <Metadata><br>
><br>
>       <MDI key="STATISTICS_MAXIMUM">255</MDI><br>
><br>
>       <MDI key="STATISTICS_MEAN"><a href="tel:111.6784426525" value="+16784426525">111.6784426525</a></MDI><br>
><br>
>       <MDI key="STATISTICS_MINIMUM">0</MDI><br>
><br>
>       <MDI key="STATISTICS_STDDEV">52.100074055799</MDI><br>
><br>
>     </Metadata><br>
><br>
><br>
><br>
> I just got stats from a subset and used that for all bands.<br>
><br>
><br>
><br>
> Duarte<br>
><br>
><br>
><br>
> De: Paul Meems (Top-X) [mailto:<a href="mailto:p.meems@topx-group.nl">p.meems@topx-group.nl</a>]<br>
> Enviada: quinta-feira, 12 de Julho de 2012 12:11<br>
> Para: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> Assunto: Re: [gdal-dev] Tiling aerial photos<br>
><br>
><br>
><br>
> Thanks Dmitry and Even,<br>
><br>
> The aerial photos are north-up and are in the same projection and I think<br>
> also in the same resolution.<br>
> It are commercial aerial photos.<br>
><br>
> The Correlator project sounds very interesting but not necessary in my case.<br>
> I'll try to implement the VRT format and see what the performance will be.<br>
> If it is fast we don't need to tile.<br>
><br>
> Thanks,<br>
><br>
> Paul<br>
><br>
> 2012/7/12 Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>><br>
><br>
> Selon "Paul Meems (Top-X)" <<a href="mailto:p.meems@topx-group.nl">p.meems@topx-group.nl</a>>:<br>
><br>
>> Thanks Even,<br>
>><br>
>> <a href="http://www.gdal.org/gdalbuildvrt.html" target="_blank">http://www.gdal.org/gdalbuildvrt.html</a> does seems very interesting.<br>
>> As I understand it, it will do the merging part (without actually<br>
>> merging).<br>
><br>
> The VRT driver will do on-the-fly merging of tiles that have overlapping.<br>
> The<br>
> VRT itself is just a XML file.<br>
><br>
><br>
>><br>
>> But it doesn't do the tiling part, right?<br>
><br>
> No, I wasn't sure if your photos were already regularly tiled or not. Note<br>
> that<br>
> the VRT accepts non regularly tiled images. They can have overlapping, gaps,<br>
> different resolutions, etc. The main constraints are :<br>
> - they are in the same projection<br>
> - they are "north-up", that is to say there is no rotation or skewing term<br>
> in<br>
> their geotransform matrix<br>
> - they have the same number of bands<br>
><br>
><br>
>> Or is the vrt so optimized tiling<br>
>> is no longer necessary?<br>
><br>
> Not necessary. Note that the VRT has no internal spatial indexing, so if you<br>
> have several dozains of thousands of images in a VRT, it might slow down<br>
> because<br>
> it will iterate over all the image descriptions (without needing to open<br>
> them<br>
> however, all the information is in the VRT) to see if they intersect with<br>
> the<br>
> request window. But I'd expect the number of images in the VRT to be really<br>
> high<br>
> for that effect to become noticeable.<br>
><br>
>><br>
>> Thanks,<br>
>><br>
>> Paul<br>
><br>
> 2012/7/12 Dmitry Baryshnikov <<a href="mailto:polimax@mail.ru">polimax@mail.ru</a>><br>
><br>
> 12.07.2012 14:36, Paul Meems (Top-X) пишет:<br>
><br>
> Thanks Even,<br>
><br>
> <a href="http://www.gdal.org/gdalbuildvrt.html" target="_blank">http://www.gdal.org/gdalbuildvrt.html</a> does seems very interesting.<br>
> As I understand it, it will do the merging part (without actually merging).<br>
><br>
> But it doesn't do the tiling part, right? Or is the vrt so optimized tiling<br>
> is no longer necessary?<br>
><br>
> Thanks,<br>
><br>
> Paul<br>
><br>
> 2012/7/12 Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>><br>
><br>
> Selon "Paul Meems (Top-X)" <<a href="mailto:p.meems@topx-group.nl">p.meems@topx-group.nl</a>>:<br>
><br>
><br>
>> Hi list,<br>
>><br>
>> I have several aerial photos and I use MapWindow GIS to view them.<br>
>> MapWindow is already using GDAL v1.8<br>
>><br>
>> Instead of loading each aerial photo as an individual layer I want to<br>
>> create a local tiles store of the photos.<br>
>> I can then just load the tiles I need based on the scale and view. This<br>
>> will most likely improve the performance.<br>
>><br>
>> The process will be something like this:<br>
>> 1. Get the filenames of the photos<br>
>> 2. Merge them into one<br>
>> 3. Create tiles<br>
>> 4. Put the tiles in a SQLite database<br>
>><br>
>> My first question: Is the above suggested process correct or should I do<br>
>> it<br>
>> differently?<br>
>> My second question: What GDAL functions should I look into to accomplish<br>
>> my<br>
>> process?<br>
><br>
> You could try to make a VRT from all your photos. It will be seen as a<br>
> single<br>
> GDAL dataset, and will take care of the burden of opening the underlying<br>
> photos<br>
> when needed. You can use the gdalbuildvrt utility to create the VRT from the<br>
> photos.<br>
><br>
><br>
>><br>
>> Thanks,<br>
>><br>
>> Paul Meems<br>
>> The Netherlands<br>
>><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
><br>
> gdal-dev mailing list<br>
><br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
> There is an interesting work connected aerial imagery:<br>
> <a href="http://trac.osgeo.org/gdal/wiki/Correlator" target="_blank">http://trac.osgeo.org/gdal/wiki/Correlator</a><br>
> <a href="http://correlatorgsoc2012.blogspot.com/" target="_blank">http://correlatorgsoc2012.blogspot.com/</a><br>
><br>
> Best regards,<br>
>     Dmitry<br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br>