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