Contraction Hierarchies routing,
MoNav is a Desktop / Mobile application that offers state-of-the-art fast and exact routing with OpenStreetMap Data.
MoNav is based on a diploma thesis by Christian Vetter and currently hosted at Google Code. In contrast to many other routing applications, MoNav offers exact routing without heuristic assumptions and with very little computational work. Its routing core is based on Contraction Hierarchies.
The application consists of several components:
- monav-preprocessor, the preprocessor, transforms raw OpenStreetMap data into its own file formats. The preprocessing is time consuming and requires larger amounts of memory, as well as an x86-64 OS.
- monav, the client application, has little hardware requirements and thus runs on desktop machines as well as on mobile devices like smartphones.
- monav-daemon, the routing deamon, can be used to provide MoNav's routing engine for other applications (like the SVN version of KDE Marble already does).
- Very fast and resource conservative routing, even on mobile devices
- Address lookup
- Driving instructions
- Highly portable - depends only on Qt
- Windows Mobile
- Linux Embedded
- Sailfish OS
- And many more
The main documentation can be found at .
The client supports the following mechanisms to render map data into its viewport:
- »OSM Renderer« fetches map tiles on demand from the osm servers. Using this rendering method is suitable on devices which are lacking disk space. As a tradeoff, an internet connection is required to fetch the map tiles.
- »Mapnik Renderer« requires tiles which are stuffed into a special binary file format. Due to the many tiles required, this will consume huge amounts of disk space. On the other hand, maps can be rendered even when no internet connection is available.
- »Qtile Renderer« requires that the preprocessor packed geometry data into a special binary file format. Map tiles are then rendered "on the fly". This method requires less disk space than the »Mapnik Renderer« and also works without an internet connection. As a tradeoff, it requires more horsepower to compute the tiles and will thus drain the battery of your mobile faster.
- GUI Mode: The preprocessor can be invoked without any command line options and will then start providing a graphical user interface. In this mode, it can be used to configure the preprocessing steps. If done, save the settings to a config file.
- Console Mode: The console preprocessor can be used to process whole sets of map packages.
Thanks to the work of James Hollingshead, MoNav 0.3 SVN contains the first incarnation of a vector renderer which aims to be a high performance renderer which creates the required map tiles "on the fly". The current SVN code is a bit awkward to compile and use, hence this posting. The following bash commands have been executed using Ubuntu Lucid 10.04.1 LTS. You will at least need Qt 4.5 dev packages, and probably some additional packages before MoNav will compile properly.
Compiling the Apps
First, let's create a directory to host the stuff we need to compile and run MoNav
Get the current code from the subversion repository:
svn checkout http://monav.googlecode.com/svn/trunk/ SVN
MoNav consists of a set of four programs. Except for the routing deamon, we will need all of them:
To compile the preprocessor-gui, use the following commands:
qmake monavpreprocessor-gui.pro && make
After that, a binary should appear in the
bin directory. Next, compile the preprocessor itself. Note that you'll need to pass DEFINES+=NOGUI on the command line:
qmake DEFINES+=NOGUI monavpreprocessor.pro && make
After that, a further binary should appear in the
bin directory. Next, compile the client, the actual "end user" application. You will need
qtmobility installed to compile the client. If you haven't (e.g. on desktop computers), use
DEFINES+=NOQTMOBILE to avoid errors:
qmake DEFINES+=NOQTMOBILE monavclient.pro && make
This should result in a third binary appearing in the bin directory:
monav monav-preprocessor monav-preprocessor-gui plugins_client plugins_preprocessor
In case nothing went wrong, the most challenging tasks are now accomplished.
Compiling the Maps
The next steps will create some map data. First create some directories to save the data necessary:
mkdir osm monavmaps
Download some osm data. Choose a small file, as the map conversion requires both time and resources. Better try a small area first and convert another file later if you are sure you are pleased with the results:
Next convert the downloaded data to MoNav map data. To ease the process, download the preconfigured file for bike routing first:
It's just an ordinary text file, editable in your editor of choice (but please remember that editor binaries always consist of two characters only). Alternatively open the file in the preprocessor GUI:
Press the button
Load Settings... and select the downloaded file
saarland.ini and adjust it to your likings. Save the settings file and close the preprocessor GUI.
Now the actual conversion is due. The preprocessor provides tons of command line switches. Let's use a couple of them:
../SVN/bin/monav-preprocessor -di -dro -dre -da -dc -t=2 --name="saarland" -s="./saarland.ini" --verbose
This will take a little time. As soon the map data is converted, it is time to open it in MoNav.
Using the Maps
In case MoNav complains a lot, delete or move its configuration file first:
mv ~/.config/MoNavClient.conf ~/.config/MoNavClient-old.conf
Choose the directory
monavmaps containing the converted map data. Then click on the map view on the left hand side of the dialog and click the button
Load. In case MoNav asks whether to uncompress the map data, confirm. MoNav then should prompt you with its viewport.
In case no map data is visible yet, click on the red circle button, choose address and select a location within your data set. This will center MoNav's viewport around the desired area. In the example above, the inner city of Speyer is shown.
- Open Source Routing Machine shares some code with MoNav
- KDE Marble uses MoNav to compute routes offline
- luckyGPS uses MoNav for various functionality