> > No. If you use the VRT directly, it is just a small XML file describing > > the > > processing you want to apply on source(s). You can use it directly as the > > input of gdal_translate -r, and the VRT specific computations will be done > > on- the-fly. > > I think here you are - at least partly - mistaken. Let me refer you to > > https://www.gdal.org/gdal_vrttut.html > > " ... For now kernel is not applied to sub-sampled or over-sampled data."
That's true... But I've just checked gdal_translate -r, gdalwarp and gdaladdo code paths, and when they request the source data (here from the VRT dataset), they request it at its native resolution (which makes sense, since after all they have dedicated code to do the resampling, so they're not going to rely on resampling done by the source driver or from the default nearest-neighbour code path), so I'm quite confident you'd get the intended effect; it is if you request the VRT filtered source at their non-native resolution that the filter will actually be completely skipped. For gdaladdo, my above observation would only be true of the first overview level you compute. For the second one, it would restart from the previously computed one, so by-passing the potential VRT filter. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
