[Qgis-developer] new generation symbology

Martin Dobias wonder.sk at gmail.com
Wed Jan 21 05:55:27 EST 2009

Hi Marco!

On Wed, Jan 21, 2009 at 9:21 AM, Marco Hugentobler
<marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin,
> I had a brief look at the symbology-ng plugin recently. It is really
> phantastic how many new possibilities of symbolisation can be used and I'm
> really looking forward to the day we have this in core. I also like the design
> as it seems straightforward to add new subclasses of symbol layer for all kind
> of symbols. It also enhances the level of compatibility with SLD for QGIS (and
> QGIS mapserver).

I'm thinking of writing RFC for it very soon, I would like to get it into 1.1.

Btw. it might be interesting to survey if it's already a superset of
SLD capabilities and if not, what's missing.
In comparison with current QGIS rendering capabilities, it lacks only
a few advanced things: transparency setting, symbol size and rotation
based on attribute values

> I also have a couple of questions:
>    - arrows: wouldn't it be more consequent from a design point of view to
> have a subclass of LineSymbolLayer for arrows, e.g. ArrowLineSymbolLayer,
> instead of a member variable in LineSymbol? Imagine people may add tons of
> other line decoration types and options for those types.

Well, but adding ArrowLineSymbolLayer would mean that people will need
to duplicate code from SimpleLineSymbolLayer and implement the
decoration. And I don't like the idea of code duplication.

But probably it would be wise to move arrow decoration from LineSymbol
to LineSymbolLayer but keep it available for any line symbol. What do
you think?

>    - renderers: there is no continuous color renderer any more. In my
> opinion, it is not necessary that you add one, but the design should allow it
> to create continuous renderers as they may be quite usefull for cartographic
> purposes. From what I saw in the code, it seems to me there is would be no
> problem in implementing such type of renderers. Is that true or did I overlook
> something?

I've left out continuous renderer intentionally. I had more reasons for that:
- you can effectively use graduated renderer with enough classes - in
fact one could implement continuous renderer as graduated renderer
with fixed number of classes (e.g. 100), fixed symbols and a
configurable color ramp
- there are some technical problems (at least in current
implementation in QGIS): symbols are recreated for every value (i.e.
slowness), it has very few configuration options (e.g. only linear
interpolation) ...
- looking at other GIS software I haven't seen continuous renderer
anywhere, so I consider it as not important

>    - api compatibility: Do you think there is a way to maintain api
> compatibility with the new symbolisation? Otherwise the new symbology code had
> to go into a branch first because it changes the way that QgsVectorLayer and
> QgsRenderer interact. That would mean it can be in stable branch for QGIS 2.0
> (which I think is unfortunately pretty late).

I think that will be possible. Imagine that we add
QgsVectorLayer::drawV2() function that will use new rendering
capabilities, while the original QgsVectorLayer::draw() will keep
working. Similarly, the new classes might be kept in an other
directory and with different names, e.h. QgsSymbolV2, QgsRendererV2.
Once this will be implemented in core library, it will be possible to
alter QgsMapRenderer, QgsMapCanvas and QGIS user interface to use the
new classes.

I'll put details into the RFC.


More information about the Qgis-developer mailing list