[gdal-dev] Tiling aerial photos

[Paul Meems (Top-X)]

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 listgdal-dev at 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 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/1354f107/attachment-0001.html>