TaxMe 2008 auf Ubuntu jaunty 9.04 amd64

The saga continues.

Nun ja,wir kennen das Muster mitlerweile: ein neues TaxMe, einen neuen Tag mit herumpröbeln verloren.

Warum schaffen es DV Informatik auch nach 4 Jahren nicht eine Version von TaxMe herauszugeben, ”’die einfach läuft”’? Man nimmt die auf dem Desktop mit Abstand verbreitetste Linux Distribution, startet Taxme und - es tut nicht.

So sieht meine TaxMe2008 Installation aus:

  # apt-get install libswt-gtk-3.4-java libswt-gtk-3.4-java-gcj libswt-gtk-3.4-jni
  $ cd TaxMe2008/libs
  $ mv linux-gtk linux-gtk.32bit
  $ mkdir linux-gtk
  $ for i in \
    libswt-atk-gtk-3448.so \
    libswt-awt-gtk-3448.so \
    libswt-cairo-gtk-3448.so \
    libswt-gnome-gtk-3448.so \
    libswt-gtk-3448.so \
    libswt-mozilla-gtk-3448.so \
    libswt-pi-gtk-3448.so \
    do; 
       ln -s /usr/lib/jni/$i
    done
   $ ln -s /usr/share/java/swt-gtk-3.4.jar swt.jar
   $ cat runTaxMe
   #!/bin/sh
   export MOZILLA_FIVE_HOME=/usr/lib/xulrunner
   export LD_LIBRARY_PATH=${MOZILLA_FIVE_HOME}:${LD_LIBRARY_PATH}
   ./TaxMeBe2008

Resultat:

• TaxMe2008 startet
• Hilfe nicht verfügbar

$ cat log.txt
        at ch.dvbern.tax.common.presentation.cd.util.BrowserUtil.createBrowser(BrowserUtil.java:76)                 
        at ch.dvbern.tax.common.presentation.cd.Taxme.createWelcomeContent(Taxme.java:323)                          
        at ch.dvbern.tax.common.presentation.cd.Taxme.createContents(Taxme.java:313)                                
        at org.eclipse.jface.window.Window.create(Window.java:431)                                                  
        at ch.dvbern.tax.common.presentation.cd.TaxmeController.startup(TaxmeController.java:911)                   
        at ch.dvbern.tax.common.presentation.cd.TaxmeLauncher$1.run(TaxmeLauncher.java:145)                         
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)                                           
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)                             
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)                                      
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)                                       
        at ch.dvbern.tax.common.presentation.cd.TaxmeLauncher.launchApplication(TaxmeLauncher.java:155)             
        at ch.dvbern.tax.common.presentation.cd.TaxmeLauncher.launchTaxme(TaxmeLauncher.java:86)                    
        at ch.dvbern.tax.be.np.presentation.cd.TaxmeBeLauncher.main(TaxmeBeLauncher.java:82)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at ch.dvbern.lib.update.Launcher.main(Launcher.java:91)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
Caused by: org.eclipse.swt.SWTError: XPCOM error -1041039359
        at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1597)
        at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:355)
        at org.eclipse.swt.browser.Browser.(Browser.java:118)
        at ch.dvbern.tax.common.presentation.cd.util.BrowserUtil.createBrowser(BrowserUtil.java:58)
        ... 23 more
org.eclipse.swt.SWTError: XPCOM error -1041039359
        at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1597)
        at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:355)
        at org.eclipse.swt.browser.Browser.(Browser.java:118)
        at ch.dvbern.tax.common.presentation.cd.help.gui.HelpApplication.createContents(HelpApplication.java:171)
        at org.eclipse.jface.window.Window.create(Window.java:431)
        at ch.dvbern.tax.common.presentation.cd.action.menu.HelpMainhelpAction.openHelpWindow(HelpMainhelpAction.java:79)
        at ch.dvbern.tax.common.presentation.cd.action.menu.HelpMainhelpAction.run(HelpMainhelpAction.java:51)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
        at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583)
        at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500)
        at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)

Und es ist notabene nach 4 Jahren immer noch das gleiche Problem: den Browser mit den externen Hilfetexten zu starten.

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:

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:

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 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!