[mapserver-dev] Coloring height rasters

[Administrator]

Frank,

I just smacked myself in the forehead.

I think what you suggested earlier was a preprocessing step that would
convert my 16 bit height data into 24 bit height data, processed as
desired and stored as a three band GDAL image.  Your new code would then
pass the data through to the output image by creating the 32 bit RGBA
pixel from the appropriate raster bands.

Is this what you had in mind ?

John Novak

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Sunday, November 24, 2002 6:56 PM
To: Administrator; mapserver-dev at lists.gis.umn.edu
Subject: Re: [mapserver-dev] Coloring height rasters


Administrator wrote:
> Frank,
> 
> If you have the capability to process raw data, and the capability to 
> quantize that data into a set of 255 user specified colors, you're 
> already touching every pixel in the raw data.  A color ramp shader 
> such as I'm simply performs a different quantization and outputs 24 
> bit values for each pixel.
> 
> I definitely agree that this is not the pinnacle of optimal code, but 
> I can have the shader use the full range of 24 bit color across the 
> heights appearing in the rectangle of interest.  Maximum detail based 
> on the height minimum and maximum.

John,

You are correct that the current MapServer code (with the recent
addition of the SCALE processing keyword) can scale the data to 0-255.
Then you could use 256 CLASS statements to set a color for each of those
values. Ideally there would be a further mechanism to specify the 256
entry color table more compactly ... perhaps as a set of interpolation
points, but that isn't strictly necessary.

> This, of course, begs the question of just where the height minimum 
> and maximums come from.
> 
> Which, conveniently, leads to my next question.  There's already a 
> very fine tile based scheme that sits on top of the shape file data 
> base format, I believe.  It seems that it would not be terribly 
> difficult for someone, namely me, to extend the row schema for each 
> tile such that it includes the min and max heights for the tile.
> 
> An appropriate tile index query could then supply the shader with the 
> height extrema for each tile in the final image so that the correct 
> ratio of height delta to pixel RGB value could be efficiently computed

> for rendering.  This means you may not get the broadest range of 
> values for a particular rectangle, but if the tile index has 
> appropriate granularity it should suffice.

This could be done, but would require an extra pass over the tile index
to collect the raster min/max values before actually drawing any of the
raster tiles.  I am not especially enthusiastic about this complication
to the code.

I suppose this could be done outside of the mapserver code base itself
if your application is MapScript based, and then you could set the layer
scaling range before calling drawMap.  That would be sweet.  Note that
there is no harm in adding extra columns in the tile index.  They will
be ignored by MapServer.

The real issue, to my mind, is that you will have a hard time generating
a proper color ramp legend showing the "real values" along a color bar.

> Maybe I could implement the range color table while I'm at it...

How do you mean?  A special way of specifing color tables from ranges
within the mapfile?

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    | Geospatial Programmer for Rent