Re-thinking RFC 6

Stephen Woodbridge woodbri at SWOODBRIDGE.COM
Wed Jun 20 00:46:07 EDT 2007


One general approach to this problem would be support both simple ramps 
in the mapfile as you describe and a color lookup file like:

[ramp name 1]
min in_val out_val
max in_val out_val
option floor|ceil|exact|nbuckets
in_val out_val
in_val out_val
in_val out_val
in_val out_val
in_val out_val
in_val out_val

[ramp name 2]
min in_val out_val
max in_val out_val
in_val out_val
in_val out_val
in_val out_val
in_val out_val
in_val out_val
in_val out_val

etc

min and max are optional and implied by the remaining values

option tells you how to clamp interpolated values by round up, round 
down, exact value, or fit in one of n buckets

in_vals that are not in the list are interpolated between the in_vals 
the bracket the value and are then interpolated based on option rules.

RANGEFILE "my_color_luts.txt" "ramp name 2"

This would allow for simple definitions in the mapfile or a more complex 
one defined outside the mapfile. This would also make it easy to 
generate complex color ramps. Also you could use the same but with 
out_val being a color.

-Steve W.

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



More information about the mapserver-dev mailing list