Subject: [Thuban-list] RFC: Layer Rendering

From: Jonathan Coles <[email-masked]>
Date: 16 Jan 2003 11:16:25 +0100

RFC: Layer Rendering
--------------------

I've noticed that the MapRenderer class contains all the logic to draw
the layers and shapes. I think that most of this can and should be moved
to another class, either Layer or LayerRenderer. When work on the layer
classification begins (see RFC: Layer Classification) there will need to
be a lot of type checking to determine what kind of shape is being
drawn, what shape property is being used for classification, and so on.
A function like layer.render(dc, ...). would clean a lot of this up and
just let the system handle what Layer to draw. 

Which leads into creating several subclasses of Layer for each type.
Each subclass would know how to draw itself and what data values are
stored in its classification data structure. This allows new types of
Layers to be drawn more easily. Ideally, Layers would know how to load
and save themselves (although the exact hierarchy for this needs some
thought; I wouldn't want to overload the class with too much work). It
seems that Layers do know how to load themselves, but a different class
is saving them. Putting all this is the same or related class has the
advantage of easily adding Layers that are stored in different formats.
Perhaps Layer loading could be a plug-in feature (I believe that this is
easy to do in Python?). 

These are just some of my rough thoughts for now.

Thoughts?

--jonathan

---

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

we discussed this IRL.

Currently the Layers should neither know how to store itself in
a file nor should it do the rendering.

Layer currently is a quite stupid class that just
holds the necessary information. Storing the infos to a file is
kept central in order to have a central point where different file formats
(or specific versions of the same format) are be read/written.
A single object (like Layer) does not know about the file format in
general and thus should not write small portions of it.

For the time being, we also keep the rendering in place, but this might
eventually change.

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

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