Proposed RFC on COLORRAMP Support (Bug 1305)

[Stephen Woodbridge]

Bill,

It is great to see the RFC on this you posted.

1) I forward the attached email as a reminder of some of my input into 
the RFC. There were other emails on this in 6/28 - 7/1/2005.

2) Please make sure %name% substitution is working and that any %name% 
can be substituted multiple times.

3) I think that support for arbitrary discrete breaks (RAMPBREAKS below, 
but call it as you wish) is extremely important. This is required for 
most demographics and especially when the classification algorithm is 
external to mapserver. You can take any range of data and classify it in 
a number different ways, like kmeans, natural breaks, quantiles, etc and 
I do not think we should expect mapserver to do all or any of these. To 
do these you need to do two passes over the data, 1. to get all the 
possible values and compute the range and break points, 2. to render the 
objects.

The use case for this is an application the lets the user select the 
classification algorithm from a list and then renders the map based on 
the classification. Simple linear ramps are not adequate and mapserver 
should not be burdened the classification algorithms BUT needs to 
support getting passed a predefined classification.

Each of the classification algorithms will define a unique set of break 
points like on the RAMPBREAKS below. You then need to present them in 
their discrete bands. Also when you classify data as above you do not 
know how many classes you are going to get back. You can specify the 
maximum number of classes that the algorithm will create, but it 
commonly creates less when you have clustering around a break point and 
natural breaks to totally dependent on the data, you might ask for 10 
breaks and get back 3. In this case you want to pick bottom of the ramp, 
the middle of the ramp and the top of the ramp.

4) Support for multiple colors on the ramp to get the black->yellow->red 
style ramps instead of doing it as classes. It seems very awkward to try 
and split up a classification ramp across multiple classes. I'm trying 
to keep the code in as few places as possible. I can generate all the 
breaks, etc outside of mapserver and I would like to pass them through 
the CGI interface (is CGI a new requirement you need to spec in the RFC) 
I would hate to have to write additional mapscript to break my ramps 
into classes.

5) You might want to consider separate out of band colors for above and 
below the color band. It seems logical, but I'm not currently needing that.

I am happy to test this with the thematic mapping application I have 
already built and needs feature like these.

Great RFC, glad you are trying to push this forward. It has been on my 
list to respond to you on this and the RFC is just what was needed to 
motivate me.

Best regards,
   -Steve W.

-------- Original Message --------
Subject: Re: [UMN_MAPSERVER-USERS] Wishing we had COLORRAMPs or something
Date: Wed, 29 Jun 2005 11:07:52 -0400
From: Stephen Woodbridge <woodbri at SWOODBRIDGE.COM>
Reply-To: Stephen Woodbridge <woodbri at SWOODBRIDGE.COM>
To: MAPSERVER-USERS at LISTS.UMN.EDU
References: <42C1F3DC.4030908 at swoodbridge.com> 
<Pine.LNX.4.58.0506282140530.2980 at fastcat.binko.net> 
    <42C21237.9070304 at swoodbridge.com> 
<931f8ea90506290727157a1c05 at mail.gmail.com>

Frank,

I will add some thoughts to the bug. Off the top of my head, I am
thinking it would be nice to have something like:

RAMPBREAKS 0 5.2 27.3 ... 503.4

Which would be used to slot the RAMPITEM into discrete ranges instead of
  continuous interpolation. This would get converted to something like

switch (RAMPITEM) {
   case <=     0: under_range;
   case <=   5.2: slot=0;
   case <=  27.3: slot=1;
   ...
   case <= 503.4: slot=n;
   default: slot=over_range;
}

then use slot 0 .. n for lookup on the ramp and
allow:

OVERCOLOR  210 210 210
UNDERCOLOR  92  92  92

These makes it very flexible the user point of view, and we have all the
information to compute varying slots on a ramp, and for create legends
based on discrete slots.

Also, on the COLORRAMP allow multiple RGB points so you can have more
colors. Like:

COLORRAMP 0 0 255   255 255 255   255 0 0

for a ramp that goes from Blue to white to red

I need to play with it more, and I will add these thoughts to the bug.

Bill,

Right, I did not use a style, I will try that when I get a chance tonight.

Frank Warmerdam wrote:
> On 6/28/05, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> 
>>Bill,
>>
>>Hey, this sounds great!
>>I will give it a try. I knew you had done some work in this area, but I
>>did not realize it was in 4.6 which I am using.
> 
> 
> Steve,
> 
> I believe the decision was to not document it as a supported
> feature for 4.6 so that we would have time to fiddle and improve
> it some more.  However, I too am keen to have some people
> use it and provide feedback with the understanding that the
> mapfile syntax and approach may change a bit by 4.8
> when it would hopefully "stabilize" as a supported feature.
> 
> Best regards,