Feature request: n-band raster layer classification

[Vincent Schut]

Frank Warmerdam wrote:

>On 2/7/06, Vincent Schut <schut at sarvision.nl> wrote:
>  
>
>>Hello mapserver-developers,
>>
>>In the near future, we are going to need raster layer classes based on
>>more than just the first band of a raster layer. 'We' means the small
>>company I'm working for, SarVision (www.sarvision.nl). We mainly develop
>>automated systems for tropical forest monitoring using satellite imagery
>>from several sensors, optical as well as radar. Besides that we offer
>>our customers/partners webgis access to the results through mapserver
>>and a dedicated webgis client.
>>
>>One of our partners would like to be able to show a layer which is
>>actually a combination of 2 or more raster layers. As an example: show
>>all pixels that have an altitude of more than 500m or that are steeper
>>than 20 degrees in red, the rest in green. Now this is still one of the
>>simpler examples, and one of the prerequisites is that the
>>classification values (500m and 20degrees) are dynamically adjustable by
>>the user. I've been thinking of several workarounds for this, but of
>>course the most suitable way would be to implement raster classes based
>>on [band1], [band2], etc. instead of [pixel]. However, I'm afraid I
>>don't have the skills to implement this.
>>
>>Could someone who is more knowledgeable on mapserver hacking elaborate a
>>bit on the feasibility of this enhancement? Would it be fairly trivial
>>to implement this, or almost impossible? Depending on our partner's
>>budget (which we don't know yet) we might even be able to sponsor the
>>implementation of this enhancement.
>>    
>>
>
>Vincent,
>
>I will say that doing this will require a substantially different
>approach from the current raster classification logic.  The current
>logic creates a "lookup table" for input raster values, classifies
>the lookup table, and then applies that lookup to the real raster
>values since the current expression handling code is rather slow
>to evaluate for each pixel.
>
>Depending on your needs, I would suggest implementing some
>sort of raster expressions as part of the GDAL VRT mechanism
>or perhaps even do the operates as a pre-processing step (invoked
>from mapscript) before mapping a resultant file.
>
>If you really want to do it directly in MapServer and you aren't
>too performance sensitive, I imagine we could come up with
>something.
>
>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
>  
>

Folks,

having read Franks answer above, he is undoubtly right... I of course 
have been thinking of several possible workarounds, on which I would 
like to hear your ideas, and you might even come up with entirely new 
ways of reaching my goal :-)

1: don't use mapserver cgi, build a mapscript based processor which 
supports this kind of combi-raster-layer thing (but how?)
2: don't even think of implementing this at the server side. Implement 
this at the client side. As I intend to develop a dedicated webgis 
client in java for this partner, this would be possible, requesting the 
several layers to be combined from mapserver cgi and using java2d/JAI to 
calculate a new image.
3: fit the 2 layers to be combined into 8 bits each, and concatenate 
each value into one 16 bit word. This gives us a 16-bit classifiable 
layer, which we can (with the necessary inside knowledge) make classes 
for that essentially create layer combinations. This effectively limits 
us to 2 layers with 256 values/steps each
4: the same approach as (3), but using a palette and classifying on the 
[red], [green] and [blue] values. This gives us 3 layers, but less steps 
per layer than (3).
5: convert the rasters to one point dataset with a dbf field for the 
value from each raster layer. Then use simple vector classification in 
mapserver. Easy, but might be not so good performance-wise.
6: [more distant future] I read something (in the cvs changlogs I think) 
about a new framework for plugin-based layertypes. Could a 'modeling' 
plugin be developed which combines the (resampled) values of other 
layers using a mathematical model (formula, logic operators, whatever, 
something like the raster calculator in GRASS)? This probably is a more 
long-term thing, but if the plugin framework would support something 
like this, it would allow for some great and till now not even dreamed 
of mapserver capabilities...

I'd love to hear some comments of you guys on these ideas...

Cheers,
Vincent.