Proof of Concept Gradient Coloring and Dev question

[Havard Tveite]

Frank,
I agree with you in most of the things you write below, but I
still think that a built-in, general way of rendering layers
based on ordinal, interval or ratio attributes using Mapserver
could be quite useful. There are cartographical rules to
support such an approach.
Mapserver currently provides built-in mechanisms that are
conveniently used for rendering layers based on nominal /
qualitative (discrete) attributes. LABELSIZEITEM can also be
used to control size in a rendering based on a quantitative
attribute (STYLEITEM?)
It is not very complicated to do customized rendering using
the basic mechanisms and Mapscript, but since quantitative
attributes are so common, it would be nice to have built in
support for rendering maps based on them. Mapscript is for
power users.
It would also be nice to have built-in support for legends
for renderings based on quantitative attributes.

For layer rendering based on quantitative attributes, what we
need to define is a CLASSITEM (which is already there). In
addition we need to specify the method for classifying and
rendering based on this item/attribute.

The CLASS object is currently a very central component of the
LAYER object. Classifying and "rendering" could be done by
using a "dummy" CLASS object with a STYLE object that specifies
the rendering (as proposed in this thread). This is, as Frank
points out, confusing, since classification is performed in the
STYLE object of a CLASS object.

Another approach is use some (new?) kind of style object (perhaps
a new name is needed?) that is a direct member of the LAYER object.
Since new elements of the STYLE object now have been suggested
that do not have a use for non-quantitative attributes, it could
perhaps be just as well to introduce a new concept at the LAYER
level instead? Classes could then be defined using the current
(discrete) CLASS approach or the "new" approach, depending on the
level of measurment of the attributes that are used for the
LAYER rendering.

This is probably not a trivial enhancement, and something for the
wish-list.
What I am worried about is that such a future development could be
blocked by the introduction of the "light-weight" gradient
colouring support.


Just some thoughts/ideas...

Håvard

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.
>>
>>What about making the functionality more "general" by for
>>instance including the following STYLE items:
>>
>>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").
>
>
> Håvard,
>
> While the idea of generalizing this to generating a set of
> classes has merit, I don't think it is suitable when you
> 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.
>
> Of course we could just call these "subclasses" breaks, but
> 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.
>
> 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
> someone to tackle the legend support.
>
> Best regards,

--
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 14, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt