[gdal-dev] GDALCreateWarpedVRT and .msk files

[Sean Gillies]

Hi Even,

I got waylaid in following up, but am finally doing so now. Yes, I can also
confirm that the .msk file is being read over the internet. I'm grateful
for the CURL logging in GDAL, it's very handy.

However, I'm perplexed by not being able to get the mask I expect from the
warped VRT I'm creating using GDALAutoCreateWarpedVRT. The source file has
a mask, but no mask materializes in the warped VRT. I have a WarpedVRT
class in Rasterio that calls GDALAutoCreateWarpedVRT and is equivalent to
the Python GDAL code you showed. It has a method that calls
GDALGetMaskFlags and here's what that reports.

with rasterio.open('https://oin-hotosm.s3.amazonaws.com/
5a324a622553e6000ce5aaf5/0/3fa181a1-425c-4e53-b49f-ea72884da097.tif') as
src, WarpedVRT(src, dst_crs=src.crs) as vrt:
    print(vrt.mask_flag_enums)

# Output:
# ([<MaskFlags.all_valid: 1>], [<MaskFlags.all_valid: 1>],
[<MaskFlags.all_valid: 1>])

The source has a per-dataset mask, but this doesn't surface in the VRT. It
reports that all the pixels are valid.

Is this the intended behavior for VRTs? Are we required to materialize the
VRT and create an alpha band to contain the derived mask?

Thanks,

On Tue, Feb 20, 2018 at 4:57 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Sean,
>
>
>
> I've just tested with GDAL trunk and latest state of 2.2 branch (but I
> think that 2.2.2 should behave the same), and when using
> gdal.AutoCreateWarpedVRT() on your below mentionned dataset, the .msk file
> is read.
>
>
>
> $ CPL_CURL_VERBOSE=YES CPL_VSIL_CURL_ALLOWED_EXTENSIONS=tif,msk
> FILE=/vsicurl/http://oin-hotosm.s3.amazonaws.com/5a324a62255
> 3e6000ce5aaf5/0/3fa181a1-425c-4e53-b49f-ea72884da097.tif python
>
> [...]
>
> >>> from osgeo import gdal
>
> >> import os
>
> >>> file = os.getenv('FILE')
>
> >>> src_ds = gdal.Open(file)
>
> [...]
>
> >>> ds = gdal.AutoCreateWarpedVRT(src_ds)
>
> [...]
>
> * Connected to oin-hotosm.s3.amazonaws.com (52.216.130.219) port 80 (#2)
>
> > GET /5a324a622553e6000ce5aaf5/0/3fa181a1-425c-4e53-b49f-ea72884da097.tif.msk
> HTTP/1.1
>
> Host: oin-hotosm.s3.amazonaws.com
>
> Range: bytes=49152-114687
>
> Accept: */*
>
>
>
> < HTTP/1.1 206 Partial Content
>
> < x-amz-id-2: oXRmqP1A9HzNTn9soSOh9vQJzGUa+lA0GbsAKa0m51H8wvZCgS31y85NAXu6
> 0r3MMjRTz1TssYk=
>
> < x-amz-request-id: BC46544B595F1D30
>
> < Date: Tue, 20 Feb 2018 11:52:54 GMT
>
> < Last-Modified: Thu, 14 Dec 2017 09:58:29 GMT
>
> < ETag: "97b96b954a22be9d7bae0bfd1f33922b"
>
> < Accept-Ranges: bytes
>
> < Content-Range: bytes 49152-114687/1730078
>
> < Content-Type: binary/octet-stream
>
> < Content-Length: 65536
>
> < Server: AmazonS3
>
>
>
> [...]
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>



-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180601/66c6d39e/attachment.html>