[Thuban-list] RFC: Layer Classification
Frank Warmerdam
warmerdam at pobox.com
Thu Jan 16 15:27:37 CET 2003
Jonathan Coles wrote:
> RFC: Layer Classification
> -------------------------
>
> Thuban currently has no mechanism for classifying the shapes that
> compose a layer. It should be possible to define classification
> properties that partition the shapes so that each partition can be drawn
> in a different way. For instance, shapes associated with counties can
> have population properties which are then color coded.
>
> There should be a Classification class that encapsulates a
> classification of a layer's shapes. It would contain the data type that
> it was associated with (this would come from the table of shape
> properties), and a list of data values:
>
> [[range_low, range_high, [data_values, ...]], ...]
>
> When a layer is drawn each shape matches its property value against the
> ranges (range_low <= value <= range_high, however <= is defined) in the
> list to find its assigned data values. These values can determine such
> things as line color, line thickness, and fill color.
>
> These data values should not be specifically defined for all types of
> layers. Polygon layers may have the three values mentioned above,
> whereas an arc layer may only need the first two. The type of layer that
> is being drawn will know what values are in the data_values list.
Jonathan,
Though not really a Thuban user, I though I would provide a bit of feedback
on this.
First, for non-ambiguous class membership for data ranges I would suggest
the test semantics be "range_low <= value < range_high", or that you make
it clear what order the classes are evaluated in so that if some classes
have overlapping ranges (even if just at the end points) that you would
know what class will be selected.
Second, when classifying continuous values it is often convenient to
have an aspect of the class (such as color) vary continuously depending
on where the data value falls between range_low and range_high. For
instance, if rendering point data with temperatures it is often nice
to have one class that continuously renders the points between blue and
red depending on where they fall in a range.
Finally, you might want to introduce a concept of a NULL class. The
classification that should be applied to features not falling into another
class. Alternatively this might just be specified as a lowest priority
class with a very wide data range.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Thuban-list
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)