[Fwd: Re: [mapserver-users] classification of a raster image is changing]

[Stefan Schantz]

Hello Frank,
thank you for your explaination. I think, that now i have a small idea, 
what the UMN Mapserver is doing with my raster image.
As I wrote, I use gdal_grid to get my raw data.
Is it right, that if I use the output format Geotiff with the option - 
ot Byte, i would avoid these rounding errors? (Also long as my values 
are <255. At least it seems so.)

In another case the values of the raw data have a range from 0 to 1E7 
(and even higher). I have the problem, that the gradient is very high, 
so that only 2 classes are shown in picture.
 Is there any way for a logarithmic pre processing like 0-3; 3-10; 
10-30; 30-100; 100-300; 300-1000; >1000
I tried to set
PROCESSING "SCALE=1,1001"
PROCESSING "SCALE_BUCKETS=1000"
in the hope, that the last buckets will get all values >1000, but this 
was thought too simple.

Now I hope, that anybody has a better idea!
Thank you!

Stefan

Frank Warmerdam schrieb:
> Stefan,
>
> I notice if I run shp2img with -all_debug set on I see the following:
>
> msDrawGDAL(fahnenankunft): using RAW_WINDOW=17 0 83 100
> msDrawGDAL(): red,green,blue,alpha bands = 1,0,0,0
> msDrawRasterGDAL_16BitClassification(fahnenankunft):
>   scaling to 65536 buckets from range=-0.000183105,24.0002.
>
> I also notice that your classes test for particular ranges of
> pixel values:
>
> EXPRESSION ([pixel] > 2 AND [pixel] <= 4)
>
> If you look at the scaling message you see that a range with not quite
> integral bounds is being scaled into buckets that will therefor not fall
> nicely on integer boundaries.  I inspected your raw data and I see it is
> all integer valued.
>
> So I believe the problem is that the odd breakdown of buckets is 
> resulting
> in rounding error in the calculations.  For instance, the value 1.0 
> may fall
> into a bucket for the range 0.9994 to 1.0001 which is centered at 0.9998.
> The expression is evaluated for the "bucket center", not the real pixel
> value, and thus it would not end up in the 1 to 2 class as expected.
>
> So there are a couple fixes.  One is to use PROCESSING directives to set
> specific bucket ranges that stay constant and are sure to handle integer
> values in a dependable way.  Another way is to use non-integer ranges in
> your classes.
>
> My suggestion is to add this to your layer:
>
>   PROCESSING "SCALE=-0.5,24.5"
>   PROCESSING "SCALE_BUCKETS=25"
>
> this would produce 25 buckets neatly containing integer values well 
> within
> the bucket (not at the edges).
>
> Read the Classifying non-8bit Rasters section of the raster data access
> document for more information.
>
> http://www.mapserver.org/input/raster.html#classifying-non-8bit-rasters
>
> Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oberflaechen_i131_red.tiff
Type: image/tiff
Size: 161120 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20090630/ca888222/attachment.tiff>