[Gdal-dev] Nodata bitmasks / null processing

[Howard Butler]

On Aug 7, 2007, at 1:01 PM, Simon Perkins wrote:

> Frank Warmerdam wrote:
>> Simon Perkins wrote:
>>> One thing though - if the GetBitmask() method is a RasterBand  
>>> method, then presumably invoking that method on a RasterBand  
>>> returned by GetBitmask() wouldn't make sense. Either this could  
>>> just raise some kind of error. Or we could make GetBitmask() a  
>>> method of the Dataset instead.
>>
>> It is up to the drivers creating custom classes for their  
>> GetBitmask()
>> result to ensure those don't in turn return bitmasks, and don't have
>> a nodata value set on them.
>>
>> I think GetBitmask() being a method on GDALRasterBand, instead of
>> the dataset is important as it clearly establishes the association.
>
> That's reasonable.

Conceivably, there could be some driver that has/needs multi- 
dimensional bitmasks, ie, GetBand(1).GetBimask().GetBitmask().  I  
have no idea what they would be used for, but are the consequences  
that dire if we support things that way?  I'm worried that we'll  
otherwise end up with a GDALBitmaskBand that still has to be treated  
specially.  Maybe this is unavoidable though.

>
>
>> I am wondering, a bit how we would represent the case where there is
>> one nodata bitmask for a whole dataset.  That it, one mask applying
>> to all bands.  Perhaps all bands just return the same object?
>
> Since users might be deleting the Bitmask RasterBand when they're  
> done with it, it probably shouldn't be _exactly_ the same object,  
> but it could be a copy of a stub that shares a lot of the  
> underlying state / cache, etc. Might be worth adding a method   
> "BitmaskType()" method returning NONE, ONE_PER_DATASET, or  
> ONE_PER_BAND , or similar. This would also subsume the "HasBitmask 
> ()" method.
>

What would a generic GDALDataset return by default, ONE_PER_BAND?   
N_PER_BAND?  I'm of the opinion that we have drivers virtualize in  
some way the case were we have ONE_PER_DATASET to be ONE_PER_BAND (or  
N_PER_BAND if were to go down that crazy route).  This is attractive  
to me because client code doesn't have to care.  Bitmasks are not  
going to be highly performant regardless, and I'd like them to be at  
least simple to deal with.

I'd like to achieve parallelism with Overviews for Bitmasks.  Maybe  
this is an unreachable ideal, but I think it is attractive.

Howard