Proof of Concept Gradient Coloring and Dev question

[Stephen Woodbridge]

Bill Binko wrote:
> On Tue, 5 Apr 2005, Sean Gillies wrote:
>
>
>>As I told Frank on IRC yesterday, I'm concerned that eventually users
>>will want this continuous style feature applied to outline colors, font
>>colors, font sizes, symbol sizes, and so on.  The mapserver style could
>>become an unwieldy object, and user data could become littered with
>>*ITEM fields.  I assert that there is nothing demonstrated here by Bill
>>Binko that can't be accomplished by N classes and simple legend
>>filtering.  These N classes and filtered legends wouldn't have to be
>>edited by hand, they could be generated using any flavor of mapscript.
>>Don't take this the wrong way, Bill, I'm not dissing your creativity
>>and hard work.  I'm not actively opposed, just wanting to make sure
>>that unintended consequences are considered.
>
>
> (First, don't worry: I'm hard to offend :)
>
> It's interesting: the very first thing I tried to do with mapserver was
> get things go "paint by number".  I had a dataset from the state of
> Florida with "average daily traffic" and I wanted to get roads to color
> accordingly.  I was actually very surprised to find that there was no way
> to use the values in the data to color the shapes.  I later figured out
> classes and the expressions there, but to get a decent display, I had to
> have 25 classes in my layer!  Since my map had 12 layers, this was NUTS!

This has been a frustration of mine also. We can get text angles from
attributes but not set colors from attributes (without defining lots of
classes). Granted a "color" is actually three values for RGB and not a
single value.

I had thought about another way of doing something similar that could be
used with attributes easily. That would be to define a named color table
using your ideas for ramps, or discrete color entries. The to reference
the named table and an attribute column.

COLORTABLE "foo"
   MINCOLOR 255 0 0
   MAXCOLOR 0 0 255
   STEPS 10
END
COLORTABLE "bar"
   COLOR 255 0 0  # 0
   COLOR 238 0 0  # 1
   COLOR 221 0 0  # 2
   ...
   COLOR   0 0 0  # n
   OFFRANGE 0 255 0 # color to display if the index is out of range
END

Then in a layer be able to reference it along with an column

COLORTABLEITEM "bar" "attribute"

Or something along these lines. I am glad that you actually implemented
a prototype and it is generating a lot of discussion. I think it shows
the need for this kind of feature.

> I'm sure there are currently solutions to this: I just think this works,
> and makes life much simpler.  To claim that this will make mapfiles
> unwieldy seems a bit backward: doing this now is clumsy.

If our mapfiles are getting unwieldy, then maybe it is time to rethink
them in general. I know this is heresy, because so much of mapserver
code it tied to the structure of the mapfiles. But they have experienced
a lot of growth over the last few years and if we want to experience
continued growth as our community grows and the needs grow we need to be
able to add features like this. Some of our most experienced users are
working about the limitations and restriction in mapfiles today by using
the C preprocessor and other tools for automatic generation of mapfiles,
based on their needs. Anyway, something for our developer to think about.

-Steve

> That said, I'm open to suggestions on better ways to structure the file
> elements!  Originally, I was going to change the existing COLOR element to
> allow you to use data fields and expressions in the RBG(A) values.  That
> was very flexible, but doing the basics became complicated:
>
> MINCOLOR 255 0 0
> MAXCOLOR 0 0 255
> MINVALUE 1
> MAXVALUE 3
> GRADIENT "foo"
>
> became:
>
> COLOR (255+((0-255)*[foo](3-1))) 0 (0+((255-0)*[foo](3-1)))
>
> It works, but it's tough to explain (I practice these on my wife :)  It's
> also quite a bit harder to implement than what I have done.
>
>
>>Additionally, "gradient fill" is not the right term to use for this new
>>concept.  A gradient fill is generally understood to be the painting of
>>a single polygon or region with a smoothly varying color.  I know you
>>understand, Frank, I am just pointing out that it would be best to head
>>off possible confusion.
>
>
> I'm not attached to the word gradient: I just based it on the Gimp tool
> that I used for picking colors.  Color-ramp seems to have been bandied
> about earlier (although I'm not a huge fan of that one either :).
>
> Again, I did this to make my maps work: I'm not picky about when/how/if it
> makes it into the main distribution.  I'm just trying to give back. :)
>
> Bill
>