[gdal-dev] Tiling aerial photos

Thu Jul 12 07:00:35 PDT 2012

One more related question.
It seems using the VRT format is the way to go.

Of course I can make a wrapper around the executable and create a VRT like
that.
I can also add the functionality to the MapWindow ActiveX control, it is
already using GDAL for lots of other stuff.
Is gdalbuildvrt.exe easily included in another application or should I
stick with the executable?

Does anybody know how QGis is doing it?

Thanks,

Paul

2012/7/12 Duarte Carreira <DCarreira at edia.pt>

> 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.dev at gmail.com]
> Enviada: quinta-feira, 12 de Julho de 2012 13:28
> Para: Duarte Carreira
> Cc: p.meems at topx-group.nl; gdal-dev at 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 <DCarreira at 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.meems at topx-group.nl]
> > Enviada: quinta-feira, 12 de Julho de 2012 12:11
> > Para: gdal-dev at 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.rouault at mines-paris.org>
> >
> > Selon "Paul Meems (Top-X)" <p.meems at 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 <polimax at 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.rouault at mines-paris.org>
> >
> > Selon "Paul Meems (Top-X)" <p.meems at 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 at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> > _______________________________________________
> >
> > gdal-dev mailing list
> >
> > gdal-dev at 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 at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120712/8cb98434/attachment.html>