Thanks Even! I'll give it a try.
Could you please help me understand the difference between two next cases.
When I do either
gdal_translate rgbmask.vrt rgb_with_external_msk.vrt -mask none -b 1 -b
2 -b 3 -of VRT
or
gdal_translate rgbmask.vrt rgb_with_external_msk.vrt -mask none -of VRT
I'm getting the same (I would say expected) result: VRT raster with 3
VRTRasterBand / 1 SimpleSource element per each band.
But if I do:
gdal_translate rgbmask.vrt rgb_with_external_msk.vrt -mask none -b 1 -b
2 -b 3 -of VRT
I'm getting VRT with:
1) 3 VRTRasterBand + 1 MaskBand
2) Each VRTRasterBand has many SimpleSource elements with various DstRect.
So it seems if we don't tell to GDAL not to use mask it copies it by
default. But why the structure of VRTRasterBand is different?
On Wed, Apr 22, 2020 at 12:09 PM Even Rouault <[email protected]>
wrote:
> On mardi 21 avril 2020 23:54:03 CEST Denis Rykov wrote:
>
> > Hello,
>
> >
>
> > I'm using *.vrt file that is built atop of COG rasters with internal mask
>
> > (PER_DATASET) + external overview file *.vrt.ovr.
>
> > These files are stored on Azure Blob Storage and I get access to them
> using
>
> > /vsiaz scheme.
>
> > I've found out that when I read data from this VRT GDAL does few requests
>
> > to *.vrt.ovr to get data and lots of requests to TIFFs to extract a mask.
>
> >
>
> > What are the ways to overcome this? I hope I can put mask into
>
> > sidecar *.vrt.msk file. Is that correct?
>
> > Is there a way to store a mask inside a *.vrt.ovr file?
>
>
>
> Hum, given a rgbmask.vrt that has a mask band, the following probably works
>
>
>
> gdal_translate rgbmask.vrt rgb_with_external_msk.vrt -b 1 -b 2 -b 3 -of VRT
>
> gdal_translate rgbmask.vrt rgb_with_external_msk.vrt.msk -b mask -of VRT
> -mo INTERNAL_MASK_FLAGS_1=2 -mo INTERNAL_MASK_FLAGS_2=2 -mo
> INTERNAL_MASK_FLAGS_3=2
>
> gdaladdo rgb_with_external_msk.vrt.msk
>
>
>
> You could probably avoid rgb_with_external_msk.vrt referencing
> rgbmask.vrt, by making it directly refer to your COG sources.
>
>
>
> Even
>
>
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
