Add support to the VRT driver to specify a background color instead of the the nodata value.

[chaitanya]

As requested by Greg Coats in  http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023030.html I am adding a patch to the VRT driver and gdalbuildvrt. This works similar to the -init option in the gdal_merge.py script.

[chaitanya]

The patch

[chaitanya]

Applied the patch in r18561 in trunk.

Waiting for reviews.

[warmerdam]

I don't seem to be fully grasping the point of this. Why the special hidenodata thing in the vrtrasterband?

As far as I can tell the hidenodata action just causes the VRTRasterBand to pretend it does not have a nodata value set. Does the nodata value get used for anything else?

Couldn't the user just not pass -vrtnodata to gdalbuildvrt? I'd like to hear a fully explanation of how this mechanism works, and is intended to be used.

[chaitanya]

VRTRasterBand has a new subelement "HideNoDataValue?". Default value is 0.

If this value is 1, the nodata value will not be reported. VRTRasterBand::GetNoDataValue?(int *pbSuccess) will return the nodata value, but the variable pbSuccess will be set to FALSE. Essentially, the caller will not be aware of a nodata pixel when it reads one.

The background will be initialised using the value specified by the NoDataValue? element. NoDataValue? will be the background.

This is useful when you want to specify a fixed background value for the dataset.

By not passing the -vrtnodata to gdalbuildvrt, we will not have the ability to set the background value/color.

Updated the docs in trunk in r18563.

[rouault]

Frank, here's how I've understood the working and purpose of the patch :

Imagine that I have several raster tiles which can contain white areas or a pixel with one of its R,G,B component being 255), that the tiles don't completely fill their global bounding box and I want the empty areas to look white instead of black.

gdalbuildvrt -vrtnodata 255 -hidenodata dest.vrt src1.tif src2.tif ... srcN.tif

will use 255 as the value to fill empty areas between tiles (see VRTSourcedRasterBand::IRasterIO()), but not report it to the application processing the VRT. Without -hidenodata being specified, an application aware of nodata would display empty areas between tiles, and even valid areas with pixels at value 255 as transparent.

When Greg mentionned this need on the mailing list, I was hesitant to go further because I didn't see a nice solution. I had imagined adding a <BackgroundValue?> element to the <VRTRasterBand> which could have been used to initialize the buffer in VRTSourcedRasterBand::IRasterIO(), but this would also have been confusing if <NoDataValue?> was used at the same time.

Dealing with nodata is always confusing, especially for VRT when you have the notion of nodata for the source files (-srcnodata option of gdalbuildvrt) and nodata exposed by the VRT band (-vrtnodata). Let's hope this new option won't add too much confusion.

[warmerdam]

Ok, I generally get it though it seems like a very specialized requirement. Something similar could have been accomplished with a normal run of gdalbuildvrt and then create another layer of VRT that would just omit the nodata value.

But I won't interfere. Within it's parameters the implementation seems ok, if a bit fragile.