Proposed RFC on COLORRAMP Support (Bug 13 05)

[Stephen Woodbridge]

Bill Binko wrote:
> On Tue, 27 Sep 2005, Ned Harding wrote:
> 
> 
>>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.
>>
> 
> 
> Gentlemen,
> 
> I agree that this feels like a bit of feature creep.  I can see why it 
> would be useful, but I believe there are two ways to accomplish this with 
> only the COLORRAMP changes currently in the RFC.
> 
> One approach would simply be to manually create several CLASSes using the
> existing EXPRESSION keyword and the new COLORRAMP feature.  So, if you
> wanted a stop level at '10', you might have this:
> 
> LAYER 
>  ....
>  CLASSITEM somefield
>  CLASS
>     EXPRESSION ([somefield] < 10)
>     COLORRANGE
>         MINVALUE 0
> 	MAXVALUE 10
> 	MINCOLOR 255 0 0 #red
> 	MAXCOLOR 255 255 0 #yellow
> 	RANGEITEM 'somefield'
> 	METHOD 'linear'
>     END
>   END
>  CLASS
>     EXPRESSION ([somefield] >= 10)
>     COLORRANGE
>         MINVALUE 10
>         MAXVALUE 20
>         MINCOLOR 255 255 0 #yellow
> 	MAXCOLOR 0 255 0 #green
>         RANGEITEM 'somefield'
>         METHOD 'linear'
>     END
>   END
> ...
> 
> Another solution would be to use Mapscript to essentially do the same 
> thing programatically.  I am sure one of the Mapscript gurus could put 
> together a function (buildColorRampClasses for example) that essentially 
> would allow this (in PHP):
> 
> $theLayer = getTheLayerSomehow();
> $stops = array(0 => '255 0 0', 10 => '255 255 0', 20 => '0 255 0');
> buildColorRampClasses($theLayer, $stops, 'LINEAR', 'somefield');
> 
> I believe the Mapscript class I described in the RFC would make this 
> fairly simple.  
> 
> A final thought would be to create another METHOD that performed this.  
> While I'm not necessarily opposed to that, a part of me worries about any
> method that would require additional keywords to do its work.
> 
> Stephen, I hope this addresses your concerns.  If not, I'm willing to take 
> another stab, or we can try it in a separate RFC.
> 
> Thanks for the feedback,
> Bill

Ned,

I can hardly argue with your impressive capabilities, but I have to 
believe that you have a fair amount of infrastructure backing up your 
thematic maps that does not exist in mapserver today. I am not 
suggesting that we build it all into mapserver either.

Bill,

Thank you for the suggestion.

As a programmer I can munge the data to fit the tools, but what I am 
trying to make sure that we have is the basics. And that other can use 
it also.

I can normalize my class values to integers, I do that today, but you 
loose all the information about the values for mapsever legends. For 
example, look at:

http://imaptools.com/~woodbri/thematic/thematic.cgi?name=ThemeMap&cmd=Map&debug=&location=MA&method=kmeans&numclasses=10&demographic=DP40063

by using the breaks you have real values for your legends instead of 
ordinal number (0,1,2,3...). Notice I created these legends in html.

I would like to avoid using mapscript to dynamically generate some N 
number of classes. It should not be required to do that for thematic 
maps. I should be able to generate a thematic map with a simple LAYER 
definition using PostGIS and get good legends. I can encapsulate all or 
most of the logic needed in Perl or postgres functions.

Here is the mapfile for the link above:
http://imaptools.com/~woodbri/thematic/thematic.map

In fact if you look at the SQL you will notice a call to imt_classify() 
which is converting the breaks into integer values based on the breaks 
that are computed elsewhere so that the integers can be used to classify 
the map.

Summary, I guess I could work with normalizing the data and using a ramp 
where I can set the min and max value as I can do that today, except 
%name% substitution does not work in the current code. I do think it is 
not so good that we are loosing the real values for the legends and 
would like to see support for that.

-Steve W.