[Fwd: Re: [UMN_MAPSERVER-DEV] Re-thinking RFC 6]

[Jan Hartmann]

Perhaps converting the start and end color to HSV (Hue, Saturation,
Value) would give values that could be interpolated in a meaningful way.
For display, the interpolated colors could be converted back to RGB. The
algorithm is elementary, i believe.

Jan

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,
> 
>