Subject: [Thuban-list] changing color ramps without reclassifying

From: "Moritz Lennert" <[email-masked]>
Date: Tue, 10 Feb 2004 16:09:21 +0100 (CET)

Hello,

During the testing of the patches, another point struck me: what is the
reason for associating classifying and color ramps in one ? Wouldn't it be
better to let the user change color ramps without having to go through the
classifying process ? This is especially helpful when creating customized
classes by hand.

Moritz

---

From: "Daniel Calvelo Aros" <[email-masked]>
Date: Tue, 10 Feb 2004 16:36:52 -0500

On Tue, 10 Feb 2004 16:09:21 +0100 (CET), Moritz Lennert wrote
> reason for associating classifying and color ramps in one ? Wouldn't 
> it be better to let the user change color ramps without having to go 
> through the classifying process ? This is especially helpful when 
> creating customized classes by hand.
> 
> Moritz

I agree. The whole classification infrastructure needs some cleanup, IMHO.

A workaround using my patch would be to reopen the genclass dialog and chosing
Custom Breaks. Then you will get whatever is the *current* classification,
although everything (incl. singletons) will be converted to ranges. Change
color and apply. Your original ranges are there, and colors are changed.

Maybe we can start a definition discussion over the interface for
classifications. I know how ArcView, ArcGIS, JUMP, OpenEV work, and the
philosophies are quite different, each with its own limitations... I guess
some kind of fill pattern editor (can we borrow the one from sketch/skencil?)
would be nice, and separating value generation from color/symbol generation.
We will have to work on this anyway for symbols, and afterwards for transparency.

Daniel.

-- Daniel Calvelo Aros
-- Dirección General de Información Agraria
-- Ministerio de Agricultura del Perú
-- (51-1)424-9001

---

From: Bernhard Reiter <[email-masked]>
Date: Thu, 12 Feb 2004 13:05:16 +0100

> I agree. The whole classification infrastructure needs some cleanup, IMHO.

Naturally we are all open to suggestions.
We were glad to have a first version of classification in there.
Then user needs and feedback like from you 
drive the analysis of the next steps.

> philosophies are quite different, each with its own limitations... 

This would be a very useful analysis indeed.
Maybe we can find a scientist for this topic.

> I guess

It is interesting that you have mentioned Skencil.
We want to go a new approach with Thuban.
To seperate the components using a concept
that I named: losely couple task oriented components.

We want to use Skencil for the detailed vector drawing capabilities.
And Thuban for the principal classification.

We had a Student at Intevation you wrote his Diplom Thetis 
about a prototype. It proves that the concept can work.

Thuban therefore export a subset of SVG, called Thuban-Map-SVG
and Skencil (0.7.x) can read it. Within Skencil you can then
exchange all symbols, by selecting them based on their classification.
Updating a layer also works.

We need to properly publish those results in the near future.