[Fwd: [Gdal-dev] RFC 15: More Band Masks]
Frank Warmerdam
warmerdam at pobox.com
Tue Aug 28 10:21:16 EDT 2007
guillaume huby wrote:
> Hi Frank,
>
> http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask
> <http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask>
>
>
> If I do not misunderstood, you wrote that mask should be of type
> GDT_Byte. Why limit to GDT_Byte ? For exemple MODIS QA bands can be of
> type GDT_UInt16 ( http://edcdaac.usgs.gov/modis/qa/mod09gq_qa_v5.asp). I
> know that you are not implementing HDF yet, but if you do it in a
> future, you might have to make changes to allow this. I recognize that
> this is a very specific case and is not necessary for the first purposes
> of your project.
Guillaume,
I choose to limit the mask bands to GDT_Byte so that the applications
can depend on this. Skimming the QA layer information I do not believe
that it would be suitable to treat *directly* as a mask band, though I
believe the HDF driver could, in theory, derive a mask band from it.
For instance, I think a mask band could be derived from the QA layer
such that QA bits of 00 or 01 mapping to 255 (valid), and 10 or 11
mapping to mask value 0 (nodata). The QA band can of course appear as
a regular 16 bit band on the dataset (as it does now I think) and
MODIS aware application can work with the full set of bits.
In order to make mask bands reasonably easy for applications to use it
is important (I think) that they have fairly straight forward semantics.
Currently the rule is that a value of zero in the mask band means "nodata"
and any other value means "valid". Intermediate values may have some
additional transparency or quality semantics in some cases but for simplistic
applications it is basically one bit of information per pixel.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
More information about the Gdal-dev
mailing list