Michael Bedward a écrit :
> Would the MaskedConvolve operator be a useful addition to the
> gt-coverage module ?
It could for images backed by integer values. For floating point values, I tend
to favor a different approach but I don't know if it is applicable in your case.
In my case, image backed by floating point values are measurements of some
geophysical quantity, for example an elevation in metres on a temperature in
degrees celcius. The areas to masks are areas where there is no data available.
I represent those data by Float.NaN value.
In some cases, we want to distinguish between different kind of "no data"
values. For example we may have an image of "Sea Surface Temperature" (SST)
measurements, with no data in some area because there is clouds, and no data in
other areas because we are on land. Some argue that we can not use Float.NaN for
"no data" value because they still want to distinguish the reason why the data
is missing (clouds, land, etc.).
This is not a well known fact, but actually there is many NaN values available
in IEEE 754. The Float.NaN constant is just one of them. We can build the other
ones with Float.intBitsToFloat(int) and a few knowledge of the bits pattern in a
IEEE 754 floating point number. So it is possible to represent "no data" values
by NaN and still be able to distinguish between "clouds, lands" or any other
category of your choice. The inconvenient is that we need to be careful with
portbility (we may have subtle difference in IEEE 754 interpretation between
different kind of processors).
If we use NaN values for "no data" instead of some special value like -9999,
then all JAI operations have a reasonable default behavior. In the case of the
convolve operator, if there is any NaN value under the convolution kernel, then
the result for that particular pixel is NaN. We don't get a totally irrelevant
value because of the mix of real data with special value like -9999; we get only
sensible result.
With the "NaN for nodata value" approach, there is no need for mask.
The inconvenient of the default implementation of the Convolve operator is that
if we use a kernel of said 4x4 and if there is only 1 NaN value among the 16
pixels under that kernel, then we get NaN. So we can loose a lot of area that
way. We could create a variant of the Convolve operator where NaN values are
ignored instead than summed.
Does it fit your use case?
Martin
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geotools-gt2-users mailing list
Geotools-gt2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
