Proposed RFC on COLORRAMP Support (Bug 13 05)

Tue Sep 27 10:56:17 EDT 2005

I know I'm not a regular here, so flame away, but I thought I'd voice my
opinion on this one since demographics is our business.

Theming demographics is one of the most important things my company does
with a map, but I'm not sure why the need for RAMPBREAKS.  If you are going
to calculate your own ranges externally (which we do), it seams like at best
that is a syntax improvement on the current class system, but it doesn't add
any new functionality.  We haven't had any problems displaying custom breaks
in the existing system, since the class let you do almost anything.  

It seams to me the big advantage of color ramps is continuous coloring
(which there is no way currently to do), for which the scale would be linear
or logarithmic.  Not that I have a problem with the RAMPBREAKS idea, but it
does seams like feature creep.  I'd rather see something get done than wait
for a better solution for something we can already do well enough.  It would
be too bad if every RFC that comes up ends up getting expanded to the point
that people are afraid to propose them because they get too big.

Ned Harding
Chief Technology Officer
SRC - Extending the Reach of Micromarketing
3825 Iris Ave Suite 150
Boulder, CO 80303
(303) 440-8896 x104

http://www.extendthereach.com

Technology in Action:

http://www.DemographicsNow.com

-----Original Message-----
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On
Behalf Of Stephen Woodbridge
Sent: Tuesday, September 27, 2005 7:26 AM
To: MAPSERVER-DEV at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-DEV] Proposed RFC on COLORRAMP Support (Bug
1305)

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20050927/34543175/attachment.html