libosmscout status update

Just a small message to make sure nobody things project is dead, while it is still alive.

What happened between this and the last blog entry:

  • Improved demo applications. Now the Illumination and Qt demos have the same feature set.
  • Improved speed of import (germany in around 40 minutes).
  • Support for *.pbf files (which improved execution time of the preprocessing step by factor 12!).
  • General improvements of the code base (more documentation and comments, improved interfaces).
  • Dramatically reduce amount of memory required (now around 20 MB or less for map of germany).
  • Finished Qt backend (visually equal to cairo backend).
  • Improved interface for map drawing backends, now even more code is implemented in the abstract base class. This should make implementing new backend even simpler).
  • Improved standard style.
  • Initial version (no dashes, no labels, no icons) of libagg backend (very fast software vector renderer).

It should now be possible to integrate libosmscout into your applications without much problems.

Next goals: Read the rest of this entry »


libosmscout now supports Qt

Libosmscout now supports Qt. Now you can use MapPainterQt instead MapPainterCairo to draw maps into a QPainter.

I also added OSMScout, a simple Qt application that mimics parts of TravelJinni (the libillumination/cairo counterpart). It not yet has all the features TravelJinni has, but already shows how map integration should be done in Qt.

Below is a screenshot of OSMScout

Screenshot of the OSMScout application

Screenshot of the OSMScout application

…and the same area as display by TravelJinni:

Screenshot of the TravelJinni application

Screenshot of the TravelJinni application

While visually both maps look very similar (small differences in text rendering) the are performance differences. While Qt claims to be fast, cairo in fact is faster for simple image surfaces (under X11). Judging from Google investigation using a OpenGl painter should burst Qt performance – but this has yet to be tested (and new version of cairo support OpenGl, too).

libosmscout and TravelJinni now working under Windows, too

Just a short notice that with the recent Illumination and libosmscout changes, TravelJinni is now working under Windows, too Read the rest of this entry »

libosmcout status update

libosmsocut is still fine. Recent enhancements did improve speed and also the visual expression . Here are the details: Read the rest of this entry »

libosmscout now supports 64 bit

Because several people tested libosmscout under 64 bit and found that it failed to work I have now taken the time to install a recent Ubuntu 64 bit image, reworked the type system for loading and storing files and now claim that at least data import and map drawing correctly works under 64 bit.

Better CityStreetIndex in libosmscout

The new version of libosmscout is now able to generate a hierarchical index for finding areas and locations. This means, that now for every area hit (e.g. searching for ‘Godesberg’) the name of the containing administrative boundaries will be given, too. For ‘Godesberg’ this means, that it will be displayed, that the ‘Godesberg’ in ‘Bonn’, which is in ‘Nordrhein-Westfalen’ which again is in Germany is meant. Multiple entries with the same name are now correctly handled. The new version also allows to index any type of data not only cities and street., but also hospitals, hotels etc…


Just started my new blog to report (besides my OpenStreetMap activities) about my development activities for maemo, and in the meanwhile maemo changed to something else (or just changed its name). Was it a mistake to start a blog ;-)?

In my opinion, the strategy to merge is in principle right, but the timing could be better, and from the development and user view it creates new uncertainties where stability and evolutionary changes are necessary in the short time. It seems that Nokia possibly did not feel well enough with fremantle and harmattan road map and thought a strong partner would be better.

Practically there is some risk to annoy a huge number of people. It is necessary that both partners clarify their vision, get the technical merging through, define what is in and what is out quickly. Getting old and new developers into MeeGo still requires a mid-term convincing plan that make people invest in the platform while there is already money to earn somewhere else. Changing release policy by officially make the N900 supported for MeeGo would surely help, too, to reassure people quickly.

What does it mean for my applications? Since I’m building my own GUI framework and already was aware of the platform switch to Qt, nothing changes for me. In contrary, the fact that Gtk is in again, avoids me having to use Qt theming code for proper platform theming. Switching to RPM seems to be more politically motivated than technically (both parties have to balance out give and take), but since I have build RPMs in the past this should not real problem.Besides WifiInfo and the code for the virtual keyboard there are not that much platform specific APIs involved. I hope that are parts that are in.

Having access to a wider range of devices in future is in my direct interest, since one of the goals of Illumination (the underlying GUI library) is to get platform independent applications with exactly these varying functionalities and constraints. Thanks 😉

May you live in interesting times…