<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.24">
<TITLE>RE: [UMN_MAPSERVER-DEV] Proposed RFC on COLORRAMP Support (Bug 1305)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Ned Harding</FONT>
<BR><FONT SIZE=2>Chief Technology Officer</FONT>
<BR><FONT SIZE=2>SRC - Extending the Reach of Micromarketing</FONT>
<BR><FONT SIZE=2>3825 Iris Ave Suite 150</FONT>
<BR><FONT SIZE=2>Boulder, CO 80303</FONT>
<BR><FONT SIZE=2>(303) 440-8896 x104</FONT>
</P>
<P><FONT SIZE=2><A HREF="http://www.extendthereach.com" TARGET="_blank">http://www.extendthereach.com</A></FONT>
</P>
<P><FONT SIZE=2>Technology in Action:</FONT>
</P>
<P><FONT SIZE=2><A HREF="http://www.DemographicsNow.com" TARGET="_blank">http://www.DemographicsNow.com</A></FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: UMN MapServer Developers List [<A HREF="mailto:MAPSERVER-DEV@LISTS.UMN.EDU">mailto:MAPSERVER-DEV@LISTS.UMN.EDU</A>] On Behalf Of Stephen Woodbridge</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, September 27, 2005 7:26 AM</FONT>
<BR><FONT SIZE=2>To: MAPSERVER-DEV@LISTS.UMN.EDU</FONT>
<BR><FONT SIZE=2>Subject: Re: [UMN_MAPSERVER-DEV] Proposed RFC on COLORRAMP Support (Bug 1305)</FONT>
</P>
<P><FONT SIZE=2>Bill,</FONT>
</P>
<P><FONT SIZE=2>It is great to see the RFC on this you posted.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>2) Please make sure %name% substitution is working and that any %name% can be substituted multiple times.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>I am happy to test this with the thematic mapping application I have already built and needs feature like these.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Best regards,</FONT>
<BR><FONT SIZE=2> -Steve W.</FONT>
</P>
<P><FONT SIZE=2>-------- Original Message --------</FONT>
<BR><FONT SIZE=2>Subject: Re: [UMN_MAPSERVER-USERS] Wishing we had COLORRAMPs or something</FONT>
<BR><FONT SIZE=2>Date: Wed, 29 Jun 2005 11:07:52 -0400</FONT>
<BR><FONT SIZE=2>From: Stephen Woodbridge <woodbri@SWOODBRIDGE.COM></FONT>
<BR><FONT SIZE=2>Reply-To: Stephen Woodbridge <woodbri@SWOODBRIDGE.COM></FONT>
<BR><FONT SIZE=2>To: MAPSERVER-USERS@LISTS.UMN.EDU</FONT>
<BR><FONT SIZE=2>References: <42C1F3DC.4030908@swoodbridge.com></FONT>
<BR><FONT SIZE=2><Pine.LNX.4.58.0506282140530.2980@fastcat.binko.net> </FONT>
<BR><FONT SIZE=2> <42C21237.9070304@swoodbridge.com></FONT>
<BR><FONT SIZE=2><931f8ea90506290727157a1c05@mail.gmail.com></FONT>
</P>
<P><FONT SIZE=2>Frank,</FONT>
</P>
<P><FONT SIZE=2>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:</FONT>
</P>
<P><FONT SIZE=2>RAMPBREAKS 0 5.2 27.3 ... 503.4</FONT>
</P>
<P><FONT SIZE=2>Which would be used to slot the RAMPITEM into discrete ranges instead of</FONT>
<BR><FONT SIZE=2> continuous interpolation. This would get converted to something like</FONT>
</P>
<P><FONT SIZE=2>switch (RAMPITEM) {</FONT>
<BR><FONT SIZE=2> case <= 0: under_range;</FONT>
<BR><FONT SIZE=2> case <= 5.2: slot=0;</FONT>
<BR><FONT SIZE=2> case <= 27.3: slot=1;</FONT>
<BR><FONT SIZE=2> ...</FONT>
<BR><FONT SIZE=2> case <= 503.4: slot=n;</FONT>
<BR><FONT SIZE=2> default: slot=over_range;</FONT>
<BR><FONT SIZE=2>}</FONT>
</P>
<P><FONT SIZE=2>then use slot 0 .. n for lookup on the ramp and</FONT>
<BR><FONT SIZE=2>allow:</FONT>
</P>
<P><FONT SIZE=2>OVERCOLOR 210 210 210</FONT>
<BR><FONT SIZE=2>UNDERCOLOR 92 92 92</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Also, on the COLORRAMP allow multiple RGB points so you can have more colors. Like:</FONT>
</P>
<P><FONT SIZE=2>COLORRAMP 0 0 255 255 255 255 255 0 0</FONT>
</P>
<P><FONT SIZE=2>for a ramp that goes from Blue to white to red</FONT>
</P>
<P><FONT SIZE=2>I need to play with it more, and I will add these thoughts to the bug.</FONT>
</P>
<P><FONT SIZE=2>Bill,</FONT>
</P>
<P><FONT SIZE=2>Right, I did not use a style, I will try that when I get a chance tonight.</FONT>
</P>
<P><FONT SIZE=2>Frank Warmerdam wrote:</FONT>
<BR><FONT SIZE=2>> On 6/28/05, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>>>Bill,</FONT>
<BR><FONT SIZE=2>>></FONT>
<BR><FONT SIZE=2>>>Hey, this sounds great!</FONT>
<BR><FONT SIZE=2>>>I will give it a try. I knew you had done some work in this area, but </FONT>
<BR><FONT SIZE=2>>>I did not realize it was in 4.6 which I am using.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Steve,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I believe the decision was to not document it as a supported feature </FONT>
<BR><FONT SIZE=2>> for 4.6 so that we would have time to fiddle and improve it some more. </FONT>
<BR><FONT SIZE=2>> However, I too am keen to have some people use it and provide feedback </FONT>
<BR><FONT SIZE=2>> with the understanding that the mapfile syntax and approach may change </FONT>
<BR><FONT SIZE=2>> a bit by 4.8 when it would hopefully "stabilize" as a supported </FONT>
<BR><FONT SIZE=2>> feature.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
</P>
</BODY>
</HTML>