Related Plugins and Tags

QGIS Planet

Automatically restarting services after upgrades on Debian and Ubuntu

There are various tools to automatically keep a Debian/Ubuntu system security wise up to date, among others the unattended-upgrades package.

Also, there’s the checkrestart script from the debian-goodies package, that scans all the open files on a system and tries to determine to what service they belong and how that service might be restarted.

The last piece that’d tie all those scripts together and would automatically restart all services that are using stale libraries or files was missing.

With the help of Michal Fiala there however is now the restart-services script, that does just that.

The script has not seen much real world usage and as such should be regarded as experimental (f.ex. by restarting /etc/init.d/screen it will as of the time of writing terminate existing screen sessions).

The script currently lives on Github. If you encounter any problem with the script then we’ll very much wellcome a patch that fixes it…

Tomáš Pospíšek

Update 18.6.2012: The most recent checkrestart (from debian-goodies 0.61) now excludes screen from beeing listed among the services to be restarted.

Generating state machines with Dia

Dia is a nice cross platform application for diagram drawing. It can be scripted via Python, which opens the possibility to generate code from Dia diagrams.

Below we’ll create a python plugin that generates C code from UML state machine diagrams. Doing the same for other languages should be trivial.

The first thing you need is Unai Estébanez Sevilla’s nice finite state machine code generator. The version that we are using here has been abstracted in order to be able to produce code in various languages.

This python plugin implements an exporter to C code. To use it, you need to put it, along with the base exporter into your local plugins directory under ~/.dia/python.

Let’s have a quick look at the code.

First we import the dia python module and the exporter base functionality:

import dia
import uml_stm_export

Then we create our C exporter class that inherits from the generic exporter:

class CDiagramRenderer(uml_stm_export.SimpleSTM):

Next we define how the beginning of our generated code file should look like. That could include general infrastructure independent of the state machine diagram at hand. In our case, we want to encapsulate the generated state machine code within a function:

CODE_PREAMBLE="void config_stm(STM_t* stm) {"

We also define the postamble to close the function. After that come generic functions that implement the class constructor init(self) and functions responsible for calling the dia object parser begin_render(self,data,filename).

Now we define our output generator end_render(self). We first traverse dia’s objects in order to find the state machine’s initial state:

for transition in self.transitions:
   if(transition.source == "INITIAL_STATE"):

The initial state state gets a special treatment: we have a special function call generated for it:

f.write("    add_initial_state( stm, %s, %s );\n" %
    (initial_state.name, initial_state.doaction))

Next we traverse all states and output code that will create them, along with functions to be called within that state to decide on where to transition next:

for key in self.states.keys():
    f.write("    add_state( stm, %s, %s );\n"
        % (state.name, state.doaction))

And finally we output all the transitions between states:

for transition in self.transitions:
    f.write("    add_transition( stm, %s, %s, %s );\n" %
        (transition.source, transition.trigger, transition.target))

and that’s nearly it. At the end of our generator we make sure to register it with dia:

dia.register_export("State Machine Cstma Dump", "c", CDiagramRenderer())

Done! Simple, isn’t it?

Finally please permit me to thank all the people that created such a powerful tool free for us to use:

  • Unai Estébanez Sevilla for the original STM generator
  • Steffen Macke and Hans Breuer, Dia’s current busy maintaners
  • Alexander Larsson, Dia’s original author
  • all the other contributors to Dia and free software
  • Panter for inviting me to their fabulous work week in Greece where most of the hacking on the generator was done and Combitool who supported this work by needing a state machine generator in their current project.

PS: Unai’s original text generator is now also “just” a “simple” addon

Generating state machines with Dia

Dia is a nice cross platform application for diagram drawing. It can be scripted via Python, which opens the possibility to generate code from Dia diagrams.

Below we’ll create a python plugin that generates C code from UML state machine diagrams. Doing the same for other languages should be trivial.

The first thing you need is Unai Estébanez Sevilla’s nice finite state machine code generator. The version that we are using here has been abstracted in order to be able to produce code in various languages.

This python plugin implements an exporter to C code. To use it, you need to put it, along with the base exporter into your local plugins directory under ~/.dia/python.

Let’s have a quick look at the code.

First we import the dia python module and the exporter base functionality:

import dia
import uml_stm_export

Then we create our C exporter class that inherits from the generic exporter:

class CDiagramRenderer(uml_stm_export.SimpleSTM):

Next we define how the beginning of our generated code file should look like. That could include general infrastructure independent of the state machine diagram at hand. In our case, we want to encapsulate the generated state machine code within a function:

CODE_PREAMBLE="void config_stm(STM_t* stm) {"

We also define the postamble to close the function. After that come generic functions that implement the class constructor init(self) and functions responsible for calling the dia object parser begin_render(self,data,filename).

Now we define our output generator end_render(self). We first traverse dia’s objects in order to find the state machine’s initial state:

for transition in self.transitions:
   if(transition.source == "INITIAL_STATE"):

The initial state state gets a special treatment: we have a special function call generated for it:

f.write("    add_initial_state( stm, %s, %s );\n" %
    (initial_state.name, initial_state.doaction))

Next we traverse all states and output code that will create them, along with functions to be called within that state to decide on where to transition next:

for key in self.states.keys():
    f.write("    add_state( stm, %s, %s );\n"
        % (state.name, state.doaction))

And finally we output all the transitions between states:

for transition in self.transitions:
    f.write("    add_transition( stm, %s, %s, %s );\n" %
        (transition.source, transition.trigger, transition.target))

and that’s nearly it. At the end of our generator we make sure to register it with dia:

dia.register_export("State Machine Cstma Dump", "c", CDiagramRenderer())

Done! Simple, isn’t it?

Finally please permit me to thank all the people that created such a powerful tool free for us to use:

  • Unai Estébanez Sevilla for the original STM generator
  • Steffen Macke and Hans Breuer, Dia’s current busy maintaners
  • Alexander Larsson, Dia’s original author
  • all the other contributors to Dia and free software
  • Panter for inviting me to their fabulous work week in Greece where most of the hacking on the generator was done and Combitool who supported this work by needing a state machine generator in their current project.

PS: Unai’s original text generator is now also “just” a “simple” addon

QGIS - the FOSSGIS week

  • Tuesday, 2012-03-20 11:00: FOSSGIS in Dessau, Germany starts with a workshop for programming QGIS plugins

    A great conference begins, with about 400 people attending presentations and workshops over three days.

  • Tuesday, 2012-03-20 14:42: Changeset c27c89045c: “Add WFS support for QGIS server. Provided by René-Luc D’Hont”

    Wow.

  • Tuesday, 2012-03-20 14.48: QGIS 1.7.4 uploaded to DebianGIS

    Ok, QGIS 1.7.4 is already a few weeks old. But current version on Debian is 1.4.0! This will be a long “new features” list for Debian users. Thanks for your work, Francesco!

  • Tuesday, 2012-03-20 16:00: Marco Bernasocchi demonstrates a fully functional QGIS on a Android tablet.

    GPS support, right click gesture, pinch zooming and offline editing plugin working. Just a few tickets are left for uploading it to Android market. Hopefully we find another great student for this years follow-up GSoC project!

  • Wednesday, 2012-03-21 16.05: Victor Olaya, author of SEXTANTE, announces his work on a QGIS processing framework with toolbox, graphical modeler, batch processing interface, etc.

    Wow!!

  • Wednesday, 2012-03-21 18.30: QGIS and GRASS user meeting at FOSSGIS

    Explaining whats going on in the QGIS code and the QGIS community. Live demonstration of raster resampling branch.

  • Wednesday, 2012-03-21 20.18: Tim announces QGIS 1.8 RC1 for April 9th.

    Test it before the hackfest in Lyon!

  • Thursday, 2012-03-22 08:00: Bad news - three days in a row without any commit from jef!

    What happened? Jürgen forgot to bring his power adapter to Dessau :-(

  • Thursday, 2012-03-22 13:30: FOSSGIS is over

    with well attended QGIS presentations and workshops.

  • Thursday, 2012-03-22 23:37: Changeset 05f7d6baea “fix warnings”, authored by jef-n

    Jürgen is back home again. Phew!

  • Friday, 2012-03-23 10:26: Changeset 585e58179d: Nathan Woodrow merges native MS SQL provider, written by Tamas Szekeres, into master.

    Good news for MS SQL users, but also for Tim: “Finally a way to stop having to use PostGIS all the time…”

What a week for QGIS! Looking forward to more news from the QGIS Hackfest in Lyon.

QGIS - the FOSSGIS week

  • Tuesday, 2012-03-20 11:00: FOSSGIS in Dessau, Germany starts with a workshop for programming QGIS plugins

    A great conference begins, with about 400 people attending presentations and workshops over three days.

  • Tuesday, 2012-03-20 14:42: Changeset c27c89045c: “Add WFS support for QGIS server. Provided by René-Luc D’Hont”

    Wow.

  • Tuesday, 2012-03-20 14.48: QGIS 1.7.4 uploaded to DebianGIS

    Ok, QGIS 1.7.4 is already a few weeks old. But current version on Debian is 1.4.0! This will be a long “new features” list for Debian users. Thanks for your work, Francesco!

  • Tuesday, 2012-03-20 16:00: Marco Bernasocchi demonstrates a fully functional QGIS on a Android tablet.

    GPS support, right click gesture, pinch zooming and offline editing plugin working. Just a few tickets are left for uploading it to Android market. Hopefully we find another great student for this years follow-up GSoC project!

  • Wednesday, 2012-03-21 16.05: Victor Olaya, author of SEXTANTE, announces his work on a QGIS processing framework with toolbox, graphical modeler, batch processing interface, etc.

    Wow!!

  • Wednesday, 2012-03-21 18.30: QGIS and GRASS user meeting at FOSSGIS

    Explaining whats going on in the QGIS code and the QGIS community. Live demonstration of raster resampling branch.

  • Wednesday, 2012-03-21 20.18: Tim announces QGIS 1.8 RC1 for April 9th.

    Test it before the hackfest in Lyon!

  • Thursday, 2012-03-22 08:00: Bad news - three days in a row without any commit from jef!

    What happened? Jürgen forgot to bring his power adapter to Dessau :-(

  • Thursday, 2012-03-22 13:30: FOSSGIS is over

    with well attended QGIS presentations and workshops.

  • Thursday, 2012-03-22 23:37: Changeset 05f7d6baea “fix warnings”, authored by jef-n

    Jürgen is back home again. Phew!

  • Friday, 2012-03-23 10:26: Changeset 585e58179d: Nathan Woodrow merges native MS SQL provider, written by Tamas Szekeres, into master.

    Good news for MS SQL users, but also for Tim: “Finally a way to stop having to use PostGIS all the time…”

What a week for QGIS! Looking forward to more news from the QGIS Hackfest in Lyon.

FOSSGIS Konferenz 2012 in Dessau

Die FOSSGIS und deutschsprachige Open Street Map Konferenz 2012 – die grösste deutschsprachige Anwenderkonferenz für Freie Geo-Informationssysteme und freie Geodaten – findet vom 20. bis 22. März 2012 an der Hochschule Anhalt in Dessau-Rosslau statt.

Sourcepole ist mit folgenden Vorträgen und Workshops vertreten:

Da mehr als 400 Teilnehmende erwartet werden, ist eine Registrierung bis zum 16. März 2012 notwendig. Das Anmeldeformular und andere organisatorische Informationen befinden sich auf der Konferenzseite.

FOSSGIS Konferenz 2012 in Dessau

Die FOSSGIS und deutschsprachige Open Street Map Konferenz 2012 – die grösste deutschsprachige Anwenderkonferenz für Freie Geo-Informationssysteme und freie Geodaten – findet vom 20. bis 22. März 2012 an der Hochschule Anhalt in Dessau-Rosslau statt.

Sourcepole ist mit folgenden Vorträgen und Workshops vertreten:

Da mehr als 400 Teilnehmende erwartet werden, ist eine Registrierung bis zum 16. März 2012 notwendig. Das Anmeldeformular und andere organisatorische Informationen befinden sich auf der Konferenzseite.

Shaded relief maps with QGIS

Creating a shaded relief map from digital elevation data is a nice way to create a backround map for web mapping or other GIS work. Thanks to the know-how and the funding from the Swiss Humanitarian Aid Unit, QGIS now has a sophisticated function for relief map generation. The method is described in detail in an paper by Marc-André Bünzli. An important part of the method is the choice of the elevation colors. The QGIS plugin has the possibility to analyse the frequency distribution of the elevation values in the DEM and to propose color changes where significant changes in the histogram occure. It is of course also possible to modify the color scheme, to insert a completely different one in the dialog or to generat a shaded maps without color.

As illustrated below, the relief map is composed by three components modulated onto the final map to give it a more three-dimensional appearance. These intermediate steps are shown here to get a better understanding of the method. In QGIS, the user directly gets the combination as a result.

  • The first component consists of a hillshade from north-west (300 degree) and an elevation color

  • The second component is a hillshade and a gray value depending on the slope angle (darker is steeper). The hillshade angle of this second component differs to the first component by 15% to have better contrast in faces towards the light source. The second component is merged to the relief map with 30% weight.

  • The third component consists of a hillshade from 270 degree and a yellow color in cells facing towards the light source. It is merged to the relief map with 10% weight

And the final relief map looks like this:

Shaded relief maps with QGIS

Creating a shaded relief map from digital elevation data is a nice way to create a backround map for web mapping or other GIS work. Thanks to the know-how and the funding from the Swiss Humanitarian Aid Unit, QGIS now has a sophisticated function for relief map generation. The method is described in detail in an paper by Marc-André Bünzli. An important part of the method is the choice of the elevation colors. The QGIS plugin has the possibility to analyse the frequency distribution of the elevation values in the DEM and to propose color changes where significant changes in the histogram occure. It is of course also possible to modify the color scheme, to insert a completely different one in the dialog or to generat a shaded maps without color.

As illustrated below, the relief map is composed by three components modulated onto the final map to give it a more three-dimensional appearance. These intermediate steps are shown here to get a better understanding of the method. In QGIS, the user directly gets the combination as a result.

  • The first component consists of a hillshade from north-west (300 degree) and an elevation color

  • The second component is a hillshade and a gray value depending on the slope angle (darker is steeper). The hillshade angle of this second component differs to the first component by 15% to have better contrast in faces towards the light source. The second component is merged to the relief map with 30% weight.

  • The third component consists of a hillshade from 270 degree and a yellow color in cells facing towards the light source. It is merged to the relief map with 10% weight

And the final relief map looks like this:

Raster resampling in QGIS

QGIS already offers a lot of possibilities to visualize raster data (contrast enhancement, color map, handling of transparent pixels, …) Last year, Radim Blazek refactored the raster provider interface and added on-the-fly reprojection support for rasters to QGIS. Very cool!

One of the few things currently missing in QGIS raster layer is the possibility to have other resampling types than nearest neighbour. The problem is that rasters appear pixelated when zooming further than the source raster resolution. So for applications like web mapping, it is important to interpolate the pixel colors and to have a broader display scale range for layers. In the last few weeks, I’ve added bilinear and cubic raster resampling to QGIS (thanks to Canton Solothurn for funding these activities!).

A lot of refactoring was necessary in the raster layer code to add resampling in a clean way. Therefore these changes are available in branch ‘raster_resampler’ of the QGIS github clone (git://github.com/mhugent/Quantum-GIS.git). It probably needs a longer period of testing to make sure every feature of the raster layer class still works properly.

The resampling option can be chosen in the raster properties dialog:

And here is the effect for a three band color image.

Nearest neighbour:

Bilinear:

Cubic:

And here for a palletted background map

Nearest neighbour:

Bilinear:

Raster resampling in QGIS

QGIS already offers a lot of possibilities to visualize raster data (contrast enhancement, color map, handling of transparent pixels, …) Last year, Radim Blazek refactored the raster provider interface and added on-the-fly reprojection support for rasters to QGIS. Very cool!

One of the few things currently missing in QGIS raster layer is the possibility to have other resampling types than nearest neighbour. The problem is that rasters appear pixelated when zooming further than the source raster resolution. So for applications like web mapping, it is important to interpolate the pixel colors and to have a broader display scale range for layers. In the last few weeks, I’ve added bilinear and cubic raster resampling to QGIS (thanks to Canton Solothurn for funding these activities!).

A lot of refactoring was necessary in the raster layer code to add resampling in a clean way. Therefore these changes are available in branch ‘raster_resampler’ of the QGIS github clone (git://github.com/mhugent/Quantum-GIS.git). It probably needs a longer period of testing to make sure every feature of the raster layer class still works properly.

The resampling option can be chosen in the raster properties dialog:

And here is the effect for a three band color image.

Nearest neighbour:

Bilinear:

Cubic:

And here for a palletted background map

Nearest neighbour:

Bilinear:

per user X11 options

One would expect that considered the complexity of gdm there would be a way to have per user X11 options. So no, there isn’t one. At least not after the great rewrite after V2.22.

However good old Unix paradigms can help us (this is all under Debian, other Unices will allow a similar trick):

$ vim /usr/local/bin/X

Add something similar like this:

#!/bin/sh
#
# start X with different options depending on user

# check if the parent gdm process that started us contains
# "--username le_gamer" in its commandline
#
if ps -p $PPID -o args= | grep -q 'username le_gamer';
then
  exec /etc/X11/X.orig $* -config /etc/X11/xorg.conf.le_gamer
else
  exec /etc/X11/X.orig $*
fi

We check whether gdm is starting us and using the parameter “–username le_gamer”. If it is, then we’re using a different config file for X.

Of course you’ll need to adapt all this, unless you are using Debian or Ubuntu. You need to adapt the path to the X Server, to the config files etc.

Why did I do that? The problem is that Intel’s X server in Ubuntu Lucid Lynx 10.04 is really unstable with DRI on a Intel GM965/GL960 graphics card.

So unless I’m playing 3D games which are a lot faster with DRI, I don’t want to enable DRI (more over, “NoDRI” is pulling less power out of my battery). So my normal config contains this:

$ cat /etc/X11/xorg.conf
[...]
Section "Device"
        Identifier      "Configured Video Device"
        Option          "NoDRI"
EndSection

So now, the only thing you need to do is replace your “normal” X Server with the new “adaptable” one:

$ sudo mv /etc/X11/X /etc/X11/X.orig
$ ln -s /usr/local/bin/X /etc/X11/X

That’s it,

Tomáš Pospíšek

per user X11 options

One would expect that considered the complexity of gdm there would be a way to have per user X11 options. So no, there isn’t one. At least not after the great rewrite after V2.22.

However good old Unix paradigms can help us (this is all under Debian, other Unices will allow a similar trick):

$ vim /usr/local/bin/X

Add something similar like this:

#!/bin/sh
#
# start X with different options depending on user

# check if the parent gdm process that started us contains
# "--username le_gamer" in its commandline
#
if ps -p $PPID -o args= | grep -q 'username le_gamer';
then
  exec /etc/X11/X.orig $* -config /etc/X11/xorg.conf.le_gamer
else
  exec /etc/X11/X.orig $*
fi

We check whether gdm is starting us and using the parameter “–username le_gamer”. If it is, then we’re using a different config file for X.

Of course you’ll need to adapt all this, unless you are using Debian or Ubuntu. You need to adapt the path to the X Server, to the config files etc.

Why did I do that? The problem is that Intel’s X server in Ubuntu Lucid Lynx 10.04 is really unstable with DRI on a Intel GM965/GL960 graphics card.

So unless I’m playing 3D games which are a lot faster with DRI, I don’t want to enable DRI (more over, “NoDRI” is pulling less power out of my battery). So my normal config contains this:

$ cat /etc/X11/xorg.conf
[...]
Section "Device"
        Identifier      "Configured Video Device"
        Option          "NoDRI"
EndSection

So now, the only thing you need to do is replace your “normal” X Server with the new “adaptable” one:

$ sudo mv /etc/X11/X /etc/X11/X.orig
$ ln -s /usr/local/bin/X /etc/X11/X

That’s it,

Tomáš Pospíšek

per user X11 options

One would expect that considered the complexity of gdm there would be a way to have per user X11 options. So no, there isn’t one. At least not after the great rewrite after V2.22.

However good old Unix paradigms can help us (this is all under Debian, other Unices will allow a similar trick):

$ vim /usr/local/bin/X

Add something similar like this:

#!/bin/sh
#
# start X with different options depending on user

# check if the parent gdm process that started us contains
# "--username le_gamer" in its commandline
#
if ps -p $PPID -o args= | grep -q 'username le_gamer';
then
  exec /etc/X11/X.orig $* -config /etc/X11/xorg.conf.le_gamer
else
  exec /etc/X11/X.orig $*
fi

We check whether gdm is starting us and using the parameter “–username le_gamer”. If it is, then we’re using a different config file for X.

Of course you’ll need to adapt all this, unless you are using Debian or Ubuntu. You need to adapt the path to the X Server, to the config files etc.

Why did I do that? The problem is that Intel’s X server in Ubuntu Lucid Lynx 10.04 is really unstable with DRI on a Intel GM965/GL960 graphics card.

So unless I’m playing 3D games which are a lot faster with DRI, I don’t want to enable DRI (more over, “NoDRI” is pulling less power out of my battery). So my normal config contains this:

$ cat /etc/X11/xorg.conf
[...]
Section "Device"
        Identifier      "Configured Video Device"
        Option          "NoDRI"
EndSection

So now, the only thing you need to do is replace your “normal” X Server with the new “adaptable” one:

$ sudo mv /etc/X11/X /etc/X11/X.orig
$ ln -s /usr/local/bin/X /etc/X11/X

That’s it,

Tomáš Pospíšek

per user X11 options

One would expect that considered the complexity of gdm there would be a way to have per user X11 options. So no, there isn’t one. At least not after the great rewrite after V2.22.

However good old Unix paradigms can help us (this is all under Debian, other Unices will allow a similar trick):

$ vim /usr/local/bin/X

Add something similar like this:

#!/bin/sh
#
# start X with different options depending on user

# check if the parent gdm process that started us contains
# "--username le_gamer" in its commandline
#
if ps -p $PPID -o args= | grep -q 'username le_gamer';
then
  exec /etc/X11/X.orig $* -config /etc/X11/xorg.conf.le_gamer
else
  exec /etc/X11/X.orig $*
fi

We check whether gdm is starting us and using the parameter “–username le_gamer”. If it is, then we’re using a different config file for X.

Of course you’ll need to adapt all this, unless you are using Debian or Ubuntu. You need to adapt the path to the X Server, to the config files etc.

Why did I do that? The problem is that Intel’s X server in Ubuntu Lucid Lynx 10.04 is really unstable with DRI on a Intel GM965/GL960 graphics card.

So unless I’m playing 3D games which are a lot faster with DRI, I don’t want to enable DRI (more over, “NoDRI” is pulling less power out of my battery). So my normal config contains this:

$ cat /etc/X11/xorg.conf
[...]
Section "Device"
        Identifier      "Configured Video Device"
        Option          "NoDRI"
EndSection

So now, the only thing you need to do is replace your “normal” X Server with the new “adaptable” one:

$ sudo mv /etc/X11/X /etc/X11/X.orig
$ ln -s /usr/local/bin/X /etc/X11/X

That’s it,

Tomáš Pospíšek

SVG symbols in QGIS with modifiable colors

SVG markers are a popular way to symbolise points in QGIS. Predefined markers are available in $PREFIX/share/qgis/svg and it is straightforward to add new symbols or to create own symbols with a vector graphics program (e.g. Inkscape). A disadvantage so far was the need to create different versions of an svg file to have the same symbol in several colors. A recent change in QGIS now introduces the possibility to insert parameter tags into the svg file and QGIS is going to replace them with the values for fill color, outline color and outline width.

It works with a syntax similar to the svg params working draft. Let’s say we have the following simple svg file:

<svg width="100%" height="100%">
<rect fill="#ff0000" stroke="#00ff00" stroke-width="10" width="100" height="100">
</rect>
</svg>

To have the possibility to change the colors of the marker, we have to add the placeholders ‘param(fill)’ for fill color, ‘param(outline)’ for outline color and ‘param(outline-width)’ for stroke width. These placeholders can optionally be followed by a default value:

<svg width="100%" height="100%">
<rect fill="param(fill) #ff0000" stroke="param(outline) #00ff00" stroke-width="param(stroke-width) 10" width="100" height="100">
</rect>
</svg>

Now it is possible to change fill color, outline color and stroke width using the new elements in the QGIS symbol layer dialog.

Replacing parameters and rendering svg can be expensive in terms of processing time. Therefore, an svg cache has been added which accelerates painting of svg markers considerably. For drawing on screen and with QGIS server, the svg markers are painted as rasters. For printing, a vectorized output is generated.

This work was funded by the Canton of Solothurn (Switzerland). Thank you very much!

SVG symbols in QGIS with modifiable colors

SVG markers are a popular way to symbolise points in QGIS. Predefined markers are available in $PREFIX/share/qgis/svg and it is straightforward to add new symbols or to create own symbols with a vector graphics program (e.g. Inkscape). A disadvantage so far was the need to create different versions of an svg file to have the same symbol in several colors. A recent change in QGIS now introduces the possibility to insert parameter tags into the svg file and QGIS is going to replace them with the values for fill color, outline color and outline width.

It works with a syntax similar to the svg params working draft. Let’s say we have the following simple svg file:

<svg width="100%" height="100%">
<rect fill="#ff0000" stroke="#00ff00" stroke-width="10" width="100" height="100">
</rect>
</svg>

To have the possibility to change the colors of the marker, we have to add the placeholders ‘param(fill)’ for fill color, ‘param(outline)’ for outline color and ‘param(outline-width)’ for stroke width. These placeholders can optionally be followed by a default value:

<svg width="100%" height="100%">
<rect fill="param(fill) #ff0000" stroke="param(outline) #00ff00" stroke-width="param(stroke-width) 10" width="100" height="100">
</rect>
</svg>

Now it is possible to change fill color, outline color and stroke width using the new elements in the QGIS symbol layer dialog.

Replacing parameters and rendering svg can be expensive in terms of processing time. Therefore, an svg cache has been added which accelerates painting of svg markers considerably. For drawing on screen and with QGIS server, the svg markers are painted as rasters. For printing, a vectorized output is generated.

This work was funded by the Canton of Solothurn (Switzerland). Thank you very much!

SVG symbols in QGIS with modifiable colors

SVG markers are a popular way to symbolise points in QGIS. Predefined markers are available in $PREFIX/share/qgis/svg and it is straightforward to add new symbols or to create own symbols with a vector graphics program (e.g. Inkscape). A disadvantage so far was the need to create different versions of an svg file to have the same symbol in several colors. A recent change in QGIS now introduces the possibility to insert parameter tags into the svg file and QGIS is going to replace them with the values for fill color, outline color and outline width.

It works with a syntax similar to the svg params working draft. Let’s say we have the following simple svg file:

<svg width="100%" height="100%">
<rect fill="#ff0000" stroke="#00ff00" stroke-width="10" width="100" height="100">
</rect>
</svg>

To have the possibility to change the colors of the marker, we have to add the placeholders ‘param(fill)’ for fill color, ‘param(outline)’ for outline color and ‘param(outline-width)’ for stroke width. These placeholders can optionally be followed by a default value:

<svg width="100%" height="100%">
<rect fill="param(fill) #ff0000" stroke="param(outline) #00ff00" stroke-width="param(stroke-width) 10" width="100" height="100">
</rect>
</svg>

Now it is possible to change fill color, outline color and stroke width using the new elements in the QGIS symbol layer dialog.

Replacing parameters and rendering svg can be expensive in terms of processing time. Therefore, an svg cache has been added which accelerates painting of svg markers considerably. For drawing on screen and with QGIS server, the svg markers are painted as rasters. For printing, a vectorized output is generated.

This work was funded by the Canton of Solothurn (Switzerland). Thank you very much!

SVG symbols in QGIS with modifiable colors

SVG markers are a popular way to symbolise points in QGIS. Predefined markers are available in $PREFIX/share/qgis/svg and it is straightforward to add new symbols or to create own symbols with a vector graphics program (e.g. Inkscape). A disadvantage so far was the need to create different versions of an svg file to have the same symbol in several colors. A recent change in QGIS now introduces the possibility to insert parameter tags into the svg file and QGIS is going to replace them with the values for fill color, outline color and outline width.

It works with a syntax similar to the svg params working draft. Let’s say we have the following simple svg file:

<svg width="100%" height="100%">
<rect fill="#ff0000" stroke="#00ff00" stroke-width="10" width="100" height="100">
</rect>
</svg>

To have the possibility to change the colors of the marker, we have to add the placeholders ‘param(fill)’ for fill color, ‘param(outline)’ for outline color and ‘param(outline-width)’ for stroke width. These placeholders can optionally be followed by a default value:

<svg width="100%" height="100%">
<rect fill="param(fill) #ff0000" stroke="param(outline) #00ff00" stroke-width="param(stroke-width) 10" width="100" height="100">
</rect>
</svg>

Now it is possible to change fill color, outline color and stroke width using the new elements in the QGIS symbol layer dialog.

Replacing parameters and rendering svg can be expensive in terms of processing time. Therefore, an svg cache has been added which accelerates painting of svg markers considerably. For drawing on screen and with QGIS server, the svg markers are painted as rasters. For printing, a vectorized output is generated.

This work was funded by the Canton of Solothurn (Switzerland). Thank you very much!

Celebrating 20 years of Linux!

Back to Top

Sustaining Members