Proof of Concept Gradient Coloring and Dev question

[Sean Gillies]

On Apr 5, 2005, at 7:17 AM, Frank Warmerdam wrote:

> On Apr 5, 2005 3:42 AM, Havard Tveite <havard.tveite at umb.no> wrote:
>> I agree that it would be nice to have a way of rendering
>> quantitative attributes in UMN Mapserver semi-automatically.
>> =20
>> What about making the functionality more "general" by for
>> instance including the following STYLE items:
>> =20
>> NUMBEROFCLASSES - the number of classes used (if not speficied,
>>                    a "continuous" rendering is performed).
>> BREAKS - The method of classification - "naturalbreaks",
>>           "equalinterval", "histogramequal", ... or the actual
>>           breakpoints ("1000,5000,7000,13000,21000,26000,29000").
> =20
> H=E5vard,
>
> While the idea of generalizing this to generating a set of=20
> classes has merit, I don't think it is suitable when you=20
> use Bill's method of putting the controls in a STYLE.  In
> fact, Bill's approach is to say that there would only be one
> class for gradient fill (what I would call color ramped) and that
> it is implemented as a specialized rendering style but STYLES
> are nested inside a single class.  So we can't very well have a
> class with a style that generates a set of classes.   At the very
> least it would be very confusing.=20
>
> Of course we could just call these "subclasses" breaks, but=20
> then you still end up duplicating alot of the descrete class
> mechanism.  Better to just manually or though mapscript
> create a set of descrete classes if that is what you want.=20
>
> I certainly do like Bill's original approach for continuous gradient
> fill.  In addition to using it for the rendering, I would also like
> legends
> to know how to show a gradient fill styled class as a color ramp with
> min, max and perhaps some intermediate values.  Of course we will
> also need some control over how these legend entries are generated.
>
> PS. I would be interested in implementing the same STYLE mechanism
> for rasters if you changes make it into CVS.  But we would still
> need=20
> someone to tackle the legend support.=20
>
> Best regards,
> --=20

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.

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.

Just my $.02
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies