About two weeks ago I blogged about my first attempts to teach MoNav to provide speech output. While everything worked well on my desktop machines, MoNav did tend to crash every now and then on the N900, rendering it pretty useless for the intended use.

As debugging was a bit difficult, I have just rewritten a suspicious part of the code. Et voilà, a test drive through the city of Karlsruhe the past evening was of great joy and pleasure.

The speech output still is not mass compliant, though. MoNav is too verbose, instructions are spoken too late, and MoNav needs too long to detect that the vehicle left the precomputed route. But that’s just tedious work in progress to be done during the next weeks and months.

And though I’m complaining, do not forget that MoNav in its current state actually is capable to guide you to your destination, while I’m pleased with what I achieved during the past weeks.

I’ll continue the work on speech output for car drivers before I’ll dive into making it compliant with the needs of cyclists.

In case you want to play with the current code, you’ll need to compile the branch from source:

You’ll also need updated map packages for this version to run properly. I’ve already precomputed some mapsets:
Germany_big
Germany
Alsace
Rheinland-pfalz
Baden-Wuerttemberg

The above lines are not intended for end users. It’s for all those openstreetmap addicts who are interested to follow the current development of MoNav.

Have fun!

A couple of months ago I opened a branch named »ui-ng« in MoNav‘s repository to develop a new user interface. Meanwhile this branch became a playground for several hacks, and some of them are just spikes to check out whether some ideas work or not.

I denied to work on speech output this spring, as I knew this would become a rather lengthy task. But it was obvious that I won’t resist the temptation during the cold and dark winter months. So I added the first code to generate spoken turn instructions recently. It is an ugly hack, just to determine what was possible. The code as found in the »ui-ng« repo works, well, at least a bit. The instructions are far away from being useful, except for lonesome crossings or roundabouts without other crossings nearby.

I’m using prerecorded samples for now, as the current open source speech synthesis systems did not show the results I desired. OTOH, this means I cannot generate instructions with dynamic contents like distances or street names. Additionally, those samples currently are included in the application binary, which will pollute the memory of handset devices as soon I’ll add further localized samples (currently speech is available in german and english language only).

The main issue is that MoNav recalculates the route each time a GPS position update is received – which means each second on the N900. As the GPS position always is a bit inaccurate, MoNav will speak »Please turn right« when you pass, for example, a gas station and the GPS position is off the road by a couple of meters.

As a consequence, I’ve just written some code that detects whether the vehicle is still “on track”. The route only gets recalculated in case the vehicle left it for more than x meters. This makes the route much more persistent and will cause far less headache than the previous approach. As this happened just a couple of minutes ago, the code is not in the repo yet.

There’s still a lot of work to do, and I’m curious whether I’ll stay motivated enough to do all of the work ahead. On the other hand it’s just plain fun to explore the secrets of a usable routing application.

So stay tuned. The next week(s) will show whether I’ll »head straightforward« :) .

The file is purged, so it just contains the route. It does not contain deviations or markers to viewpoints, museums etc. Its length is about 547 kilometers, and it contains 6014 trackpoints, so it should fit into the memory of current Garmin devices easily.

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.

MoNav performing bicycle routing

Christian Vetter, the inventor and maintainer of MoNav, just announced the release of MoNav 0.3. Finally the improvements and new features developed during the last weeks and months are available as precompiled installers. Here’s a copy of the original posting:

—

Hello everyone,

I am pleased to announce the release of the 0.3 version of MoNav
[1][2][3] just in time for your favorite Easter holiday trip.

The highlights of this release are:

• UI Overhaul, take a look at the screenshots[4]
• Offline vector renderer: QTileRenderer[5]
• Better handling of map data and map modules: It is now very easy to switch between routing ( motorcar, bicycle, pedestrian ) and rendering modes ( online, offline vector… ).
• Full Maemo support
• Track logging
• PBF[6] support: 10 times faster OpenStreetMap data parsing!
• Console version of the preprocessor
• Improved import of OpenStreetMap data: surface, smoothness, barriers, …
• And many more

Of course MoNav still delivers blazingly fast routing, even for huge
graphs on mobile devices.

Downloads available[3]:

• Client binaries for Windows32, Ubuntu 32/64 and Maemo
• Map packages for most countries: pedestrian, motorcar and bicycle routing; online and offline vector rendering.

We are still looking for contributors in the following areas:

• GUI design
• Address Lookup ( Karlsruhe Schema, novel approaches … )
• Binary package maintenance for various systems / distributions
• Usability tests and improvements
• New features
• Of course other contributions are always welcome If you believe you can contribute and are interested in joining the development team please let us know.

Feel free to contact us on our mailing lists[7][8] or to post bugs to our bug tracker[9]

Disclaimer:
Please note that this project is under active development and while
considered stable may still contain serious bugs.
Comments, bug reports and suggestions are welcome and can be filed under [9]

Happy routing!
Christian Vetter

[1] MoNav Homepage: http://code.google.com/p/monav/
[2] MoNav at OpenStreetMap Wiki: http://wiki.openstreetmap.org/wiki/MoNav
[3] MoNav Downloads: http://monav.openstreetmap.de/
[4] MoNav Screenshots: http://code.google.com/p/monav/#Screenshots
[5] QTile Renderer: http://code.google.com/p/monav/wiki/QTileRenderer
[6] PBF at OpenStreetMap wiki: http://wiki.openstreetmap.org/wiki/PBF_Format
[7] MoNav mailing list: http://groups.google.com/group/monav-discuss
[8] MoNav developer mailing list: http://groups.google.com/group/monav-dev
[9] MoNav bug tracker: http://code.google.com/p/monav/issues/list