MoNav Street Name Rendering in Kandel

Thanks to the work of James Hollingshead, MoNav now provides street name rendering at high zoom levels. This required a change in the map file format, though, so the currently available maps (which admittedly are rather dated) won’t work with binaries built from the current tip of revision control.

The new code is already available for two months now, but I hadn’t had the time to check it out. Today I got the client to compile on Max OS X 10.7.2 (aka Lion). I did not get the map preprocessor compiled, neither on Lion nor on the server, due to missing mapnik dependencies, but I got it compiled on my local Linux box.

The above screenshot shows the inner city of Kandel in Rhineland-Palatinate. I usually use this state for test runs for creating maps, as its file size is acceptable for my desktop machine.

I’m quite grateful that James did the work of creating the first vector renderer for MoNav, and that he now also added street name rendering. The next step is to get the preprocessor compiled on the server, though this might take a little while as the map processing script needs adjustments too. For Maemo on the N900, an updated binary is already available via the repo. Before you install it, ensure you have updated map data available. Otherwise you will end with an updated binary which cannot load the map data present on the device – a rather useless constellation from a user’s point of view.

Thanks a bunch, James.

Mail Icon, Tango Project

I used KMail from its early days, and was always more than pleased with it. With the switch from KDE 3 to KDE 4.3, performance issues have been introduced so managing mailing lists became inconvenient. Since the switch to KDE 4.7, things got worse, so I decided to use another mail user agent.

Apple Mail had difficulties to read some of the mbox files for no obvious reason, as the file contents appeared to be OK.

During analysis, I noticed KMail had also created a mixture of mbox and maildir files in my archive. This means I spent a couple of hours to put things right before I got everything imported into Thunderbird. Meanwhile I think I should have abused Dovecot to migrate the messages between both clients.

Here are a couple of hints concerning the migration from a (rather huge) archive containing mixed mbox and maildir messages:

• KMail uses hidden directories to save the messages. To make them visible on Mac OS 10.7 (aka Lion), use the following Terminal command line. Replace TRUE by FALSE to undo this setting after you are done: defaults write com.apple.finder AppleShowAllFiles TRUE && killall Finder
• Kaosmos provides a very useful Thunderbird extension which allows to import mbox files.
• Charalampos ‘DiAvOl’ Pournaris provides a PHP script which converts a maildir to the mbox format.
• In case your KMail archive only contains maildir mailboxes, Bruno Cornec’s Perl script might be useful for you.

Thanks for the code, guys!

Today I imported an ics calendar file from my Linux box into iCal. After the import, the entries weren’t editable. Fortunately the ics format is a simple, human readable text based format which can be read in a text editor. The file contained a couple of suspicious entries which read as

ORGANIZER:MAILTO:user@foo.bar

Since I do not use Apple Mail (and the mail address in the file was deprecated anyway) I assumed that iCal does not know this email address and interprets those events as organized by another person, setting them to read only as a consequence. It’s easy to fix this by completely removing those entries. In case you dislike command line applications, you may want to leave and file a feature request right now :) .

• Remove the imported, read only calendar from iCal and quit it.
• Go to the Applications folder, open the Utilities folder and launch Terminal.
• Ensure to execute the following commands by pressing enter after entering each command.
• Type cd Desktop to make your Desktop the current working directory.
• Type mkdir calconversion && cd calconversion – this will create a folder on your Desktop and make it the current working directory.
• Copy your ics file to this directory, named yourfile.ics
• Type the following command to create a second file with the ORGANIZER lines filtered out: cat yourfile.ics | grep -vi organizer > yourfile-purged.ics
• Start iCal and import the file yourfile-purged.ics. All entries now should be editable.
• Remove the folder containing the two temporary files from your Desktop.

That’s it.

I didn’t use it much. It mainly served me to create binaries of some cross platform applications I was working on. However, it’s CPU speed and amount of RAM are a bit limited for nowadays requirements. Additionally some contemporary applications denied to run on Tiger, and updating the OS on the feeble machine was not an option. Thus I bought a more recent machine powered by Lion s/h:

Its base size is more than the one of its predecessor:

I’m glad that Apple dropped the optical drive – I didn’t use one for years, and even if, only to convert some of my audio discs to ogg files. As a consequence, the new Mini is a bit thinner than the older model. Here’s its connectivity:

The user can easily access the RAM slots just by turning and removing the bottom of the device:

The overall operation feels much smoother now, and it operates quite well on the recently purchased Dell display. I already ported all of my data from my Dell Notebook to the Mini, as it will serve me as my primary desktop machine. I’m pretty curious whether I will find a replacement for any application I was used to on the Linux notebook. Of course I will :) .

I’m using and contributing code to Linux on the desktop for more than a decade now. I still prefer to use KDE as a desktop environment, and its mail user agent is one of the best I ever used.

Recently I upgraded my operating system to Ubuntu 11.10 aka Oneiric Ozelot. The migration of my PIM data went fine, except for my mail archive. I used some command line magic to port my data, and I also wiped all index related files in my mail directory. I’m still experiencing some glitches, though.

File indexing always was an issue on my system. While I like the idea, I always had to struggle with it, and I still do:

A MySQL database server now is required for kmail and akonadi, which often causes the fan of my notebook to operate at its maximum speed:

Incoming mails often cannot be moved to subfolders by the rules I use for filtering messages (e.g. from mailing lists):

I’ve also seen some empty mails where I do not know whether they contained important content. Some thread tends to crash every now and then, which I assume is related to the empty mails:

I tried to solve the issue by updating folders via the context menu from within the mail application. Since the progress is not visible for the user, I accidentally created some conflicts:

Sent mails sometimes appear twice, one copy in the outbox, one in the sent mail directory. This way I can not really judge whether mails have been sent or not.

I’m pretty sure this all is caused by my rather huge mail archive or some rather barbed settings file. But due to the sheer amount of issues, I wonder whether I should try to find the cause. In case someone could provide a hint, it would be great.

As open source software developers we often do not gain acknowledgment for out hard work. Despite the abovementioned issues, I’d like to express my gratitude to all of the developers of the great free software I’m using. Especially KMail served me very well over the years, and it always was a joy using it. Thanks girls and guys!

The last two days I’ve worked on a first translation system for MoNav. Thanks to Qt4 it was just simple, and admittedly I copied over some lines of code from one of my other projects, Gebabbel.

MoNav checks the user’s system for a locale string, searches for a matching translation file, and if available, it gets loaded. Currently, the translation files are included in the binary, so we do not need to care about install paths and the like. As soon we have some translations available, they will be removed from the binary and installed as separate files to save some memory.

This also means we are in desparate need of translators for the upcoming releases. Do you want MoNav to appear in your mother tongue, maybe Russian, Chinese, or Bamanankan? As no programming skills are required to create a translation, do not hesitate to contact us.

Today my way led from Darmstadt to Aschaffenburg, where I visited some relatives and friends. MoNav did a very good job guiding me. As it chose a route which led along major roads, I set a via point in Messel, and got really great results.

The trip info page I recently introduced was very helpful. Well, it’s like a progress bar on computers. It does neither shorten the remaining distance, nor does it beam you to the destination. But anyway, it’s very useful to have some figures right at your fingertips during the tour, so you know whether you should hurry or you can enjoy a short rest.

The trip was about 50 kilometers which I planned to cope with in 2 hours. Though the terrain is completely flat, some head wind caused an average speed of 20 km/h only – I needed 30 minutes more as I planned.

Once again, I really enjoyed to have MoNav’s excellent offline routing available during the trip. Before I used MoNav, I spent hours in front of my computer to prepare a trip. Today, I just check what MoNav suggests before I leave and help it with some via points – that’s it. An issue of minutes, not hours.

I’d like to thank all Co-Mappers who contributed the data I used during today’s trip. Thanks girls and guys.

¹ According to echo $RANDOM

Though I’m currently rewriting the user interface of MoNav, I’m still missing some features while being on the road. During a trip, I want to see information about the remaining route distance, the distance and time already traveled, and as a cyclist who sometimes crosses hilly regions, I found some altitude information very useful. Obviously some volunteer is needed to write the code to accomplish that. Waiting for someone else is a valid option, but I know it’s much better to get things done™ :) .

I pushed the first code to the central repository a couple of minutes ago. It’s not polished yet, and the user interface requires some more dedication. I’d also like to add a display of the average speed, but this required some redesign of the track logger code first.

Frankly, it’s a great joy and pleasure to contribute to MoNav. I’d like to thank its creator and maintainer, Christian Vetter, for the great work he put into it. The use of Qt for the backend and the frontend code. The uber fast routing engine. The use of OSM data for routing and the fast address search. And last but not least for his openness when it comes to new ideas and changes. Oh, and did I mention MoNav ran on the N900 out of the box from the first day I tried it :) ?

I’d also like to thank James Hollingshead who wrote the first ready to use vector renderer for MoNav. Though it still shows some minor glitches and is missing rendering of street names, it currently serves us very well for displaying offline vector map data.

Enough rant for now. The code is written, and I better should go to bed :) .

The recent 0.3 release of MoNav provides a useful interface, which allows to invoke all features directly from its main window. It’s a great, both finger as well as user friendly interface, especially on mobile devices such as the Nokia N900. The downside is that it does not conform to the look and feel of the other applications of a given platform.

Rant

We have been discussing this issue during this year’s FOSSGIS fair, and Martin Fowler greatly points out exactly the issues that arise from using cross-platform toolkits.

An end user, who has no clue about software development, will never understand why »there is this cool app foo, but it only is available on platform bar.«. On the other hand, a software developer who has written this cool code foo may want to make it run on as many platforms as possible.

Back in the days I contributed code to Navit, it provided a plugin system for its user interface. Though this might have changed, none of them really served me well at that time.

What does this mean for my currently favourite pet project, MoNav? I’m currently doing exactly what Martin objects to (with reason). I try to create a user interface which contains the usual UI controls other applications provide – toolbars, menubars, you name it. I add some defines to make the user interface a bit more conformant on Maemo, then Android, then Win and finally Mac OS X. One day I will notice that editing the code without breaking the user interface of a particular platform becomes more and more difficult.

MoNav already provides a backend only process for calculating routes. Theoretically it was simple to build a web application using the toolkit used, Qt. But transforming an application like MoNav within one minor release is not what you really can do in your spare time. As a consequence, MoNav will keep it’s current cross platform user interface for some time.

User Interface Changes

What follows will probably form the base of the upcoming 0.4 release. The buttons spread over the viewport have disappeared. Instead, a toolbar as found in other Maemo applications has been introduced:

I removed the possibility to add buttons for each via point. Instead, the button to select the destination of the route now provides several modes. One lets the user create a direct route to the destination. A second option can be used to create incremental routes (»From my home to the viewpoint to the biergarten and back home.«). A third one lets the user insert points between the current location and the destination (»From my home back home, but first to the viewpoint and then to the biergarten.«). I’m not sure whether those modes will make it into the final 0.4 release. Currently it’s there to be tested, mainly by myself:

On the desktop (Win, Ubuntu) MoNav now provides standard menus. On Maemo, which does not provide standard menus but one united menu only, it now looks like the following figure. Please ignore the Trip Information and the placeholder button, as those are only there for experimental features I’m currently hacking :) :

The new user interface has its advantages and its disadvantages. I’ll use it for the next couple of weeks to determine whether it is better than the previous one or not.

Compilation

In case you want to try it as well, you’ll need to compile it from source. As the repository recently was switched from SVN to Mercurial, you’ll need it installed on your system. The following example commands are untested and only provided as examples:

• /scratchbox/login (Maemo only)
• hg clone https://monav.googlecode.com/hg/ monav
• cd monav
• hg update -C ui-ng
• qmake monavclient.pro && make (for Maemo)
• qmake DEFINES+=NOQTMOBILE monavclient.pro && make (Linux Desktop)
• qmake DEFINES+=NOQTMOBILE monavclient.pro && mingw32-make (Win Desktop)
• qmake DEFINES+=NOQTMOBILE monavclient.pro -spec macx-g++ && make (Mac Desktop)

Recruiting

In case you find MoNav interesting and you want to contribute, do not hesitate to contact us. Besides other many other things, someone who cares about the Android port or creates a professional icon set to replace the current artefacts would be more than welcome. The current renderer could need some improvements (rendering of street names, for example), and there’s a possible alternative to it called libosmscout.