[gdal-dev] Tiling aerial photos

Duarte Carreira DCarreira at edia.pt
Thu Jul 12 05:03:02 PDT 2012


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<mailto:even.rouault at mines-paris.org>>
Selon "Paul Meems (Top-X)" <p.meems at topx-group.nl<mailto: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<mailto: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<mailto:even.rouault at mines-paris.org>>
Selon "Paul Meems (Top-X)" <p.meems at topx-group.nl<mailto: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<mailto:gdal-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev



_______________________________________________

gdal-dev mailing list

gdal-dev at lists.osgeo.org<mailto: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<mailto: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/df46a666/attachment.html>


More information about the gdal-dev mailing list