[gdal-dev] missing nulls in vrt from GRASS rasters

[William Kyngesburye]

On Jun 6, 2009, at 1:37 PM, Even Rouault wrote:

> William,
>
> you didn't mention how you have generated the VRT. If it's with  
> gdalbuildvrt,

Yes, gdalbuildvrt.
>
> I've just commited a change in trunk (r17201) that probably solves  
> your
> issue. It appears that when a source has a nodata value, it is not  
> sufficient
> to set it at the VRTRasterBand level. It must also been specified  
> for each
> source by using a ComplexSource instead of a SimpleSource, so that  
> nodata
> pixels from the source are not drawned on the destination buffer.

Will you be backporting this to 1.6 then?  Then I can get it into my  
GDAL framework binaries for OSX until a future 1.6.2 release.

> You can fix your VRT manually by replacing all SimpleSource  
> references by
> ComplexSource and by adding a <NODATA>256</NODATA> inside each
> <ComplexSource> element.
>
This did the trick.  thanks.

> Note that with qgis from svn trunk, I could manage to make it display
> correctly RGB images whose bands are of type UInt16 (it displayed only
> black), even when specifying the value range as 0...255 instead of the
> default 0...65535. I had to edit manually the VRT so that the  
> VRTRasterBands
> are declared as Byte. This appears to be a qgis issue/feature, as  
> openev can
> display correctly the same VRT.
>
gdal_translate also had the missing nulls.  With the manually fixed  
vrt above, gdal_translate and Qgis 1.1 display correctly.


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan