When using to mosaic on the fly large collections of images, is it better to add overviews (pyramids) to the individual rasters or to the final .vrt, or both? (Where "better" means finding the balance point between using no more storage than necessary while still providing a smooth experience for using and browsing the final image.)

  • i want to ask what is the reason of using mosaic – luka tumba Jul 9 '19 at 16:09

It depends mostly on which is the minimun scale to show your image layer.

Creating overviews for individual rasters is more flexible when you update your layer partially. Just delete old image and put a new image with overviews in place. If you have build overviews for the .vrt you must create it again after update. However, individual overviews do not work well in small scale. If your original images cover 10x10 km each and you want to show on screen an area of 100x100 km the system must open 100 individual files for reading the overviews. If you have created overviews for the .vrt there is only one file to open and it will be faster.

You can also use a hybrid model: build a few internal overview levels (2 4 8) and then create a new physical file from .vrt with pixel size of the next overview (16). Create internal overviews for the subsampled image and finally combine all together into a scale dependent group. When individual images are changed to newer ones the physical overview file often does not require updating because changes are not visible at small case anyway.

When it comes to the need of disk space, it is the the same in both cases. But remember to compress your overviews. With aerial images you can save more than 90% of disk space by compressing overviews with JPEG method and photometric interpretation.

As you put your question I would say that create compressed overviews for your .vrt. It takes the same amount of disk space and browsing experience will be good at any scale. Remember still what I wrote about updating.

  • the hybrid idea is very interesting! I'm curious about why a physical file at level-16. Does that offer something gdaladdo foo.vrt 16 32 64 doesn't? ...it also occurs to me: both tiled and vrt overviews might be wanted in instances where individual tiles are access as well as the virtual mosaic. – matt wilkie May 25 '15 at 16:48
  • gdaladdo foo.vrt 16 32.64 creates a physical file but if you did gdaladdo foo.vrt 2 4 8 before you have already a foo.vrt.ovr file. Well, .ovr file is really just a tiff and you can rename it and build overview levels by hand with a new .vrt file that that is a bit complicated. Do you mean that you have foo_1234.tif in a virtual mosaic all_foo.vrt but some users might need to access that single tiff directly? Then you are right, no software can guess to take overviews from all_foo.vrt.ovr. – user30184 May 25 '15 at 17:00
  • Oh, perhaps you meant to write 2 4 8 overviews for individual images and 16 32 64 ... for the vrt. Excellent idea indeed. – user30184 May 25 '15 at 17:07
  • yes to the 2nd response, 2 4 8 for tiles and 16 32 64 for vrt. – matt wilkie May 25 '15 at 18:54
  • The problem being discussed is one I am frequently trying to hack around and it is constantly a cause of agony. I have a huge amount of files arranged in folders of 10 km2. For each folder I generate a vrt and add overviews (2 4 8 16). I then aggregate the vrt-files in one (gdalbuildvrt aggreg.vrt *.vrt). Creating one overview for the aggreg.vrt (32 64 128 256) is a pain. I suspect that gdalbuildvrt goes directly to the source files instead of the already built ovr files... Is this correct? And if so: Is there a workaround? – user83648 Oct 2 '16 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.