Re-thinking RFC 6

[Paul Ramsey]

Two color ramps generally only work well when one of the colors is white 
or black.

Three color ramps can work will, particularly if white is the middle color.

And I've done some very nice elevation maps with a 5 color ramp.

But the general point is well taken: good ramps allow you to put N 
stakes in the ground.

P

Daniel Morissette wrote:
> Interesting idea. I think I like it, but I'm not sure if I might not be 
> missing some possible drawbacks of it.
> 
> Back to RFC-6 itself, one problem I've always had with it is that doing 
> linear interoplation of RGB values between (r1, g1, b1) and (r2, g2, b2) 
> doesn't necessarily give a good looking color ramp. Others with more 
> experience dealing with colors than me could better comment, but I think 
> you'd almost need a color lookup table, or have the ability to specify 
> multiple r,g,b points that define a path in the RGB space instead of 
> just the start and end point.
> 
> Daniel
> 
> 
> Steve Lime wrote:
>> I agree on the naming. Will have to ponder that. I'd like an syntax 
>> that would accommodate colors and numbers in the same way:
>>
>>   PARAMETERLIMITS #FFFFFF #FF0000 or PARAMETERRANGE 1 10
>>
>> (we can handle that in mapfile.c) and then
>>   ITEMLIMITS 1000.0 50000.0
>>    or something like that.
>>
>> The machinery is very similar to that of RFC 19, you just use a 
>> msBindLayerToRange function that works just like msBindLayerToShape 
>> (same parameters even). Most of the plumbing is in maputil.c already, 
>> as is the original range code Bill Binko wrote.
>>
>> Steve
>>
>>>>> Frank Warmerdam <warmerdam at POBOX.COM> 06/14/07 11:18 PM >>>
>> Steve Lime wrote:
>>> Hi guys: As the deadline for RFC's approaches I wanted to float a 
>>> change to RFC 6 that might be doable by 5.0. I've not spent time 
>>> updating the RFC yet. The idea would be to bind properties to ranges 
>>> much like RFC 19. We'd extend the range concept to  colors, sizes and 
>>> angles. So COLORRANGE would become RANGE. RANGEs would live at the 
>>> layer level and would be referenced by name so you could have several.
>>>
>>> A range would be defined as:
>>>
>>> typedef struct {
>>>   char *name;
>>>   attributeBindingObj item; /* holds name and index */
>>>   colorObj mincolor, maxcolor; /* only colorObj's and numbers make 
>>> sense */
>>>   double minnumber, maxnumber;
>>>   double minvalue, maxvalue;
>>>   int intervals;
>>>   int method; /* should be enum - MS_RANGE_METHOD */
>>> } rangeObj;
>>>
>>> and a layer would have an array (fixed size, might be ok, should need 
>>> more than a couple, or dynamic) of these.
>>>
>>> Styles properties (color, outlinecolor, size, angle) could then 
>>> reference these by name.
>>>
>>> e.g.
>>>
>>> LAYER
>>>   NAME 'myLayer'
>>>   ...
>>>   RANGE
>>>     NAME 'sizeRange'
>>>     ITEM 'sizeitem'
>>>     MINNUMBER 1
>>>     MAXNUMBER 10
>>>     MINVALUE 1000.0
>>>     MAXVALUE 500000.0
>>>   END
>>
>> Steve,
>>
>> I sort of like this approach though it seems like substantial
>> machinery might be needed to support it.
>>
>> I also really think that you need to make it more clear what are
>> input values and what are output values. Perhaps min_in_val,
>> max_in_val, min_out_scalar, max_out_scalar.  For me "value" and
>> "number" are too general to work out which is input and output
>> of the function.
>>
>> Best regards,
> 
> 


-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632