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 > listgdal-dev@lists.osgeo.orghttp://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
