Subject: [Thuban-list] RFC: Layer Classification

From: Jonathan Coles <[email-masked]>
Date: 16 Jan 2003 10:46:56 +0100

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.

There would then have to be an appropriate dialog to allow these values
and ranges to be set.

Thoughts?

--jonathan

---

From: Bernhard Reiter <[email-masked]>
Date: Thu, 16 Jan 2003 11:43:17 +0100

> Thoughts?

Just that classification might get more complicated later,
possible requiring more data and computation.
Then just a list of data values or ranges might not be enough.
If I got your design idea right then the Classification class will
encapsulate this so it should be fine.

It makes sense to implement the simple one first, too.

---

From: Frank Warmerdam <[email-masked]>
Date: Thu, 16 Jan 2003 09:27:37 -0500

> RFC: Layer Classification

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, [email-masked]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

---

From: Jan-Oliver Wagner <[email-masked]>
Date: Mon, 20 Jan 2003 17:53:17 +0100

On Thu, Jan 16, 2003 at 09:27:37AM -0500, Frank Warmerdam wrote:
> the test semantics be "range_low <= value < range_high",

we'll apply this rule.

> red depending on where they fall in a range.

it seems that there are three types:
	- discrete (eg 1,2,3 or 'ruin', 'city')
	- range (eg 0-2.5, 2.5-3.75, 3.75-65.123)
	- continous (as you described)

discrete and range is no problem and will be implemented first.
continous is a bit different since it couples a drawing property
(color, line thickness, ...) directly to the value.
Eg: range 1-15.6 corresponds to color (0,0,0)-(0,0,255)

Jonathan, I guess you should keep this third type of classification
in mind. Maybe it is not too complicated to implement it.

> class with a very wide data range.

This concept will be implemented.

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/

Intevation GmbH	              	     http://intevation.de/
FreeGIS	                               http://freegis.org/