Turn instructions are useful as a written summary when printing routes. They're even more important in turn-by-turn navigation mode, the feature Siddharth Srivastava added recently during his GSOC project. If you know the routing support in Marble 0.10, you may wonder how these new turn instructions differ from those displayed there. The first difference is that there are different icons, each indicating the turn type. Icons are a great time-saver in stressful situations -- e.g. when navigating through an unknown city. The second difference is that we have full control over the generated text: Marble (or you) can decide whether to include street names, remaining times or distances. Last but not least the awesome KDE translation teams will take care of translating all texts into your native language!

With turn instructions available for offline routers, we can work on the next logical step: Detect a deviation from the route in turn-by-turn navigation mode and automatically trigger a re-calculation of the route in the background.

Are you good at drawing icons? The turn indicator icons above are OK for a start, but some polishing surely wouldn't hurt. After all, I'm not an artist Feel free to work on the existing svg or redesign it from scratch (oxygen style, please) and send a new one to marble-devel@kde.org. Looking forward to any contributions!

Like the versions released earlier, the packages are based on the Qt version of Marble. It's the first time we provide one-click install packages, though. They're expected to install seamlessly using the graphical program manager. Marble can be started from the application menu afterwards. Notice that the one-click installer above installs the light version of Marble (5.7 MB) that only has the OpenStreetMap theme installed. Install marble-maps from the Navigation section of the program manager to get all other themes. Please report feedback to marble-devel@kde.org.

*The fine print:

We call the packages stable because they come off the stable (KDE/4.5) Subversion branch. Indeed I don't expect any serious bugs. However, we are aware of some annoyances in the current user interface that we plan to improve in the upcoming versions. Please don't report any bugs against the tab bar on the left taking too much space, some dialogs being hard to navigate or some map themes rendering slow. We are aware of this and plan to fix it. With that in mind, have fun using Marble on Maemo

Besides improving the user interface and responsiveness, we do have exciting new features like offline routing and a turn-by-turn navigation mode in the pipeline for 4.6 / Marble 0.11. Are you interested to help out? We can use all sorts of talents who help us improving graphics, write documentation, sort out bugs or add new features... Please join our mailing list or lurk around in #marble on Freenode.

Notice how the hillshading -- activated via the checkbox in the Legend on the left -- gives a nice terrain impression. This is where alpha blending comes in. Hillshading won't work with Marble 0.10.0 because alpha blending is not available there yet. Of course the Hike & Bike Map can also be used in conjunction with our Maemo version on the Nokia N900:

If you look closely at the screenshot, you'll notice another new feature in the Routing department: Monav can now be used as an alternative offline router. In contrast to the Hike & Bike Map, this feature is not available in the 4.5 / 0.10 series of Marble though.

Adding yet another offline router is justified by both gosmore and routino being unable to calculate longer routes on the N900. Monav is able to calculate a route of 250 km in less than two seconds on my N900 - with the potential to do it even faster in the future. Different transport types, turn restrictions and driving instructions are not supported yet, so it cannot be used as a full replacement for the others at this time.

The two screenshots are taken from SVN trunk btw. Can you spot the new features added by our three GSOC students?

]]> http://nienhueser.de/blog/?feed=rss2&p=156 5 http://nienhueser.de/blog/?p=147 http://nienhueser.de/blog/?p=147#comments Sun, 08 Aug 2010 14:06:50 +0000 Dennis Nienhüser http://nienhueser.de/blog/?p=147 Last time I wrote about offline routing in Marble: Calculating routes between two or more places without the need for Internet access. This was realized using gosmore. In the meantime Niko Sams added support for routino, another offline router, to Marble. My last commit adds traveling salesman support, an offline router written in java. All of this will not be available in KDE SC 4.5, but 4.6.

Most users will only need zero or one offline routers. With three of them supported by Marble, the question arises which one to choose? Ignoring their underlying algorithms and configuration options for now, I collected some high-level statistics. They show the relative differences of map sizes and response times. The response time was taken as the minimum response time among three or more runs, each measuring the time from sending a route request to the application until the full retrieval of the response in Marble. I chose two routes, a short one and a longer one, and compared the response times both on my desktop system and my N900:

Each of them was fed the same map area, a part of Germany where the OpenStreetMap raw xml data (uncompressed) has a size of 1420 MB. All routers convert the OSM map to their own format. Here a first significant difference shows up: Routino needs the least space (132 MB), followed by Gosmore (230 MB). Traveling Salesman creates a database as big as 1250 MB, a severe disadvantage for mobile applications like the N900.

Both Gosmore and Routino show good response times on a desktop system for small and medium size routes. Traveling Salesman however let's you wait a couple of seconds: too long for a satisfying user experience. On the Nokia N900, Gosmore runs considerably faster than Routino. This may be because I used a newer version of Gosmore (SVN trunk) on the N900 than on the desktop system (Kubuntu Lucid package).

To answer the original question: Both Gosmore and Routino are good choices for a desktop system. Gosmore may be easier to install because it is packaged in several distributions, while Routino needs less space to store maps. The current version of Traveling Salesman in its default configuration is not a convincing alternative for its use in Marble yet. For Maemo and the N900, Gosmore is the better choice because of its higher speed. Routino may still be an alternative if space is an issue.

Having offline routing available in Maemo leads to another nice feature to be implemented soon: Re-calculating a route when deviating from it in navigation mode. Stay tuned

Offline Bicycle Routing in Marble on the Nokia N900

While releases need their time to stabilize, development continues distributed in git repositories and in subversion trunk. Siddharth Srivastava is making great progress on his GSOC project Marble to Go with a major part of his work already in reviewboard. I'm sure he'll give an overview in his blog when it hits trunk. I'll focus on a different topic today. Marble's routing capabilities rely on OpenRouteService in KDE SC 4.5. Although it works great in most situations relevant to me, there are two major disadvantages: The OpenRouteService integration in Marble requires Internet access to retrieve routes and OpenRouteService itself is limited to Europe.

Recently Nic Roets announced a new routing webservice demo which can be accessed via a HTTP API as well. It is similar to yournavigation.org with a major difference: The server offers much more performance and can keep OSM data in RAM, therefore routing requests do rarely time out. Moreover, it serves routing requests for all areas covered by OSM. In other words, we can now do worldwide routing in Marble using this service.

One problem solved, another one still around: Relying on Internet access to retrieve routes can be expensive or even impossible at times. Ultimately we want to integrate vector maps in Marble and use them for routing; for now I found a simpler solution that enables offline routing. It uses a local installation of gosmore to retrieve routes. The drawback here is that you need to take care to install gosmore and its maps on your system. Once they're there, you have a fast routing solution for Marble however which can be used without Internet access.

If you kept counting, you'll notice that Marble (in trunk) retrieves routes from up to three different sources. This poses some questions: Do the routes differ? How? Which one is the best? Compare these two screenshots (today's trunk):

Alternative Routes in Marble

Although the distances are pretty much the same, the routes to take differ in most parts. This is an interesting information that can be used to tell the user about two equally well suited alternative routes. In other situations, the routes retrieved may be very similar and it's enough to show the best of them. This serves as a good short-term roadmap for Marble's routing feature: Sort routes by score (how well do they match the user's preference? Do they provide turn instructions? Are they localized?), filter similar ones and provide a "semantic" difference description of alternative routes. "4.0 km (Gosmore)" in the screenshot above would be replaced with "Via Adenauerring (4 km)" and "Via Kriegsstraße (4 km)" then.

Given the length of this blog, I'll stop for now and write a follow-up that addresses how to install gosmore and gosmore maps for use in Marble in more detail soon.

If your navigation device (or whichever software you want to use) does not support the .gpx format directly, have a look at gpsbabel as a universal conversion tool.

To get my hands dirty with some non-artificial examples, I wrote a small QtDeclarative plugin for Marble. It exposes MarbleWidget -- designed to be re-used in other applications -- to QML. The first thing I tried was a little game, resembling a game popular in a German TV show.

That went pretty well, but doesn't make too much use of Marble's features yet. Moving on to imitate the user interface of a popular search engine:

I was quite surprised to see how well the C++ part and the QML part play together: For example, the red search result markers you see in the screencast are only known to QML, but not to Marble. Therefore the QML part needs to update them when zooming or panning the map, which it does in the onViewportChanged handler exposed by the Marble QtDeclarative plugin.

The QML files for both applications are each less than 300 lines of code in total. The Marble QtDeclarative plugin used by them adds another 400 lines of code. That's remarkably little code needed to power two quite different user interfaces. No doubt Qt 4.7 will be a very interesting release.

Please note that none of this will be available in KDE 4.5. Support for QtDeclarative and sample QML applications may be added later to Marble, nothing decided yet. I'll push the code to gitorious after a cleanup, however.

We spent some time on polishing our maemo packages in the last weeks. Marble on maemo surely has not yet reached the state where your grandmother would be happy to use it. Her grandchild however must not be a marble developer anymore to get it running. In other words, it's time to distribute it to a wider audience.

Marble on Maemo comes in two flavors: A light variant that only contains OpenStreetMap, and a full version with different earth and moon map themes. The light variant with its nearly 6 MB is not as light as it could be; we'll squeeze it further in future versions.

If you have a spare Nokia N900 lying around which you want to dedicate to test experimental packages, please have a look at our garage project. Packages ready for the N900 can be downloaded there. See the Release Notes on installation instructions.

Disclaimer: The packages are built from a very recent subversion checkout. They were only tested on a handful of devices yet. All sorts of breakage is to be expected. Use at your own risk.

Kudos to the brave testing the packages: I'd like to hear back from you. Just show up in our IRC channel (#marble on freenode) or drop a mail to marble-devel.

Someone requested a video of marble running on the N900. I tried to do a screencast using the load applet, but the result is not too good because of this bug. If you watch it, ignore the last four minutes, they show the same picture over and over...

Marble's properties -- fast, visually appealing, easy to use, minimal hard- and software requirements, offline usable, free software and open standards -- make it appealing for a Maemo port. Working on the base of earlier ports, we're polishing things up for the N900 for some time now. Some parts of the user interface clearly need more work, but we do have a functional and reactive version running already.

In the spirit of "release early, release often" I'd go for a first release soon. We set up a Marble Garage Project for that. Give us some weeks for final polishing and we'll have packages ready.

The internal GPS device and routing via openrouteservice.org are supported as well. Does that make it a navigation device? Kind of.

You can use Marble on the N900 to plan a route and track your current position. But there is no guidance yet and other features one expects from a real navigation device are lacking as well. Call that a chance: Until Friday, students can file an application for Google Summer of Code "Marble to Go (Navigation Mode)". I'm happy to hear from you

Back in the days when Google was only a search engine I used a free (as in beer) service -- was it called Map & Guide? -- to create these printed routes. Even short routes resulted in four or five pages, quite a mess in a car. Todays services are much better, creating customizable, short printouts. Tomorrow I want Marble to print my routes.

Soon I realized that this feature is easier realizable than expected: Marble already has printing support for maps and Qt's QTextDocument simplifies creating printable pages with a nice layout. Below is a screenshot from my printing Git branch:

But adding each and every piece of information just because I can is not the goal: I rather have a slick user interface and leave confusing information out. Things that I'd call clutter, however, may be useful to someone else. At which point I thought that collecting some feedback on usefulness and clutter would be a good way forward. Ten questions on a single page, nothing more. Thanks.

]]> http://nienhueser.de/blog/?feed=rss2&p=76 8