Create Track of Route

Issue #30 resolved
Elias Kue created an issue

The Routing option is an awesome addition, but it would be great if one could turn it into a track to be able to see a height diagram. Thank you for the great work so far!

Comments (42)

  1. Michel Durand

    I would say that even without elevation graph (or height diagram) it would be useful to be able to convert a calculated route into a track.

    A good reason is : when time comes to transfer the prepared trip to the GPS, tracks are better than routes, because with routes it is not always 100% sure that the GPS will follow what was prepared on the PC screen. Same when sending the trip to friends by email : with tracks there is no doubt that trip will be kept unchanged.

  2. sergem1

    Second that, making track from a route would help to see elevation profile. Elevation profile from a route is the only reason I am keeping Garmin Basecamp in my Windows VM. When making a track, it would be nice to grab elevations from the currently selected map (use case: make route in opencyclemap, create elevations in Garmin map that has elevations). Thank you for the awesome tool!

  3. kiozen

    I don't know if you are aware of it but you don't have to draw a route if you want to have a track. Drawing a track is the same as drawing a route. So you can start with a track right on the spot.

    As routes can't be exchanged with devices in the shape they are calculated they are pretty senseless from my point of view.

  4. sergem1

    Thanks, kiozen, this totally works. Draw a track using a routing engine, then edit it and load elevations from DEM, then bingo - you have a track profile with elevations. Now, it would be nice if it was painted in different colors for uphill and downhill, but this is a different enhancement request (and you can vote for it, too!)

  5. Michael Waldor

    Routing works really, really great.

    But there seems to be one difference between a route and a track: A route might contain hints for turning ("cue sheet"), while a track cannot. If I create a route, I can add turning hints automatically (great!), but they are not stored within GPX (also the automatically added routing points are not stored). If I create a track with routing enabled, the additional routing points are stored, but there is no possibility to activate turning hints.

    If GPX can store cue information it would be great to enable turning hints for tracks, too. Or to enable storing of routes including the added routing points and hints.

    Of course if GPX would include turning information I don't know if GPS devices would use them at all:-(

  6. kiozen

    Neither the format for routes nor the format for tracks include a commonly accepted field for turn-by-turn instructions. The accepted format for routes is an ordered collection of waypoints that has to be passed by the route. The way between those points is either a straight line or a polyline calculated by the device.

    Garmin extended the route format by proprietary tags to transfer a calculated route to a devices. The content of the tags is unknown.

  7. eric bechet

    Hi, I'm willing to use Qmapshack for planning cycling trips. I tried both options (crating a route or a track) and they have shortcomings with respect to my goal : get a usable gps track that i can upload into a gps-enabled handheld device (be it a garmin or a smartphone)

    • Route is the most versatile tool, allows easy edits and refinements of the itinerary, however, AFAIK, it is impossible to export that to a decent GPX after routing. It only saves a couple of points (the one the user defined) with straight lines in between. (I do not want to let the gps unit compute the track by itself - it is just not good at that at all)
    • Track is easy to define at first, but almost impossible to edit. Too many points. For a long trip, which need many changes during planning, editing is way too cumbersome. On the other hand, Tracks can be exported to a decent GPX file.

    The only way to get the benefits from both is to have the possibility to export a "routed" route to a track. Another point : if you have only online routing available, then it is also impossible to "route" a track ! That makes the tool almost useless in that case (except for displaying maps !)

    I hope this will convince the developers that adding that small feature is a real plus for the software. I do not see any drawbacks to that...

  8. kiozen

    In track edit mode you can easily select a complete range of track points and delete them. In the next step you can add a point to the straight line and do an alternative planning. It's really easy.

  9. Michel Durand

    One problem is that online routing results from MapQuest can not be used directly as a track. Then converting a "Mapquest-routed route" into a track would help here.

    (and yes when creating tracks (and not routes) using Routino, it is easy to rework them by selecting ranges of points)

  10. eric bechet

    Kiozen, Sure. Have to select first (in the right mode) - cannot zoom / unzoom while doing this, by the way, which is a pain because there are so many points. (imagine with a 50km+ track !) Then click O, delete, click A again, click + add point, and with some luck it works. Why click O ? because otherwise it reroutes before you add a point ! My mouse screams ! Yes you can, definitely. But It is NOT easy, it is cumbersome ! And as mentioned, it does not work for online routing - so why should we do differently for online routing and offline one ? Turn it the way you want, it's not a feature for me, it's closer to a bug :)

  11. Michel Durand

    About "cannot zoom / unzoom while doing this", maybe you are referring to issue #80, which is solved now. To get this correction you should compile from current source code (version called "v1.6.0 pre"). If you want I can put somewhere in the cloud my own Windows installer, made with code from 3-4 weeks ago and working fine.

    Then the procedure to modify an existing track is :

    • switch to edit mode

    • activate "range select" tool (CTRL+R)

    • zoom in to select accurately the first point

    • zoom out

    • pan using keyboard arrows

    • zoom in to select accurately the 2nd point

    • click on the paper bin icon : now you have 1 straight segment

    • rebuild the segment using "add point" tool (CTRL + +)

  12. eric bechet

    Thanks for the info - but still cumbersome. I indeed compiled the code from a "stable" version ! And non, windows is not an option for me ;) BTW, is there a compelling reason not to be able to convert from route to track (other that just saying it is useless) ? I'm willing to do it myself, if anybody points me where to start in the code.

  13. Michel Durand

    Excellent idea ! If you do it I pay you a beer :)

    Unfortunately I do not know anything about C++ programming, QT, etc..(Ok well I know that program lines should terminated by ; ) then I can not help ...

  14. Christian Eichler

    One thing first: If you really think, that creating a track is cumbersome, then please consider improving the process (a hint: you already can use keyboard shortcuts to switch between modes) at first. The indirection "Creating a Route" - "Convert it to a Track" has a huge drawback: Once you have a track (without the corresponding route), you cannot use an online router anymore. At the end it might be intelligent to allow using an online router while creating a track instead of implementing a conversion from route to track (possible implementation: select a range of points and click route between points somewhere in the context menu). Of course you should not try to use a online router for "on the fly" routing (high load on the server, most of the calculations will be aborted anyways).

    The Route itself basically only exists, because it is part of the .gpx "standard" - it is barely used within QMS

    If you now still think implementing a conversion from route to track is a good idea, here are some hints:

    A route is internally called CGisItemRte (gis/rte/CGisItemRte.h) and contains (amongst some other things) several routepoints (rtept_t). A track is internally called CGisItemTrk (src/gis/trk/CGisItemTrk.h) and contains (again amongst some other things) several trackpoints (trkpt_t).

    As you might imagine, your main task is transfering/transforming all the data from a CGisItemRte to a CGisItemTrk, especially all rtept_ts to trkpt_ts. It should be clear that some information will be lost during that transformation (such as detailed routing descriptions).

    Some general information on hacking QMS can be obtained from the wiki. To shorten the (potential) merge process please have a look at the coding guildlines.

    One additional call: If you hit on any bugs (this applies to both "cumbersome usage" and "QMS died"), please create a report in the Bugtracker. For tips howto report a bug click here.

  15. Rainer Unseld

    Once you have a track (without the corresponding route), you cannot use an online router anymore

    The original demand was "create track from route", which implies to keep the route. This would allow to recalculate the route later-on with different routing options, or to move, add or remove route points, recalculate and create another track.

  16. Christian Eichler

    Disregarding the original demand (which was btw closed as wontfix for a reason): I do not see any good reason to distribute functionality among two different types (routes/tracks).

    Eric "reanimated" this topic by writing "I tried both options, but both have shortcomings" - but I don't see the real benefit you have, if you add a one-way conversion from route to track (it might work for you, but at the end you still have shortcomings).

    To get rid of these limitations (as far as I can see) two things need to be implemented:

    • "routing on demand" for (parts of) tracks (using online and offline routers)
    • store subpoints (the small circles you get from the router) instead of automatically converting them to ordinary trkpt_ts. These subpoints ofc will need to be exported as ordinary trackpoints to .gpx

    As soon as this is implemented you will have basically everything you need (just because it behaves similar to routes).

    Don't get me wrong - if you/anyone want/s to implement a conversion from track to route, then feel free to do so. (I'm not deciding weather a feature will be merged or declined.)

    But that is - imho - only a workaround for a single usecase, whereas a proper implementation of the points mentioned above will increase the comfort at many points (p.x. if can dynamically do routing for some trackpoints on an existing track without creating a new route and converting them to a track and merging it with the previous track).

  17. Rainer Unseld

    As already mentioned, the drawback of routes is that if you copy them to a GPS device the routing may differ from what you saw on your PC. For me, this makes routes unusable for bike or hike trips. On the other hand, editing routes has a lot of advantages over editing tracks. One common way of working (with other tools) is to plan a route, convert it to a track once your are finished and transfer it to the GPS device. In this case, no need to modify the track but you always go back to the route for editing.

  18. eric bechet

    Okay, thanks for the comments -Rainer Unseld perfectly understood what I meant. Becomes interesting . Let me be clear - it seemed to me that the way the route behaves is the right one when editing paths. Few control points, move them freely, automatic update of the calculated track, add/remove points and so forth, and ability to recover the control points after a save. The track (with a lot of points) was then an end product that is not as easily edited. The current route paradigm, although it seem to be there just because it exists in GPX files, has actually a lot of advantages when it comes to editing, as mentioned above. In fact, I fully adhere to the fact that it is a better idea to add such nice editing features to a track. For me it would do the job. But as a beginner user I simply found it easier to just add a conversion tool. I did not know the history of the project and the fact that the track is actually the core datastructure.

    Ok. So would the addition of "control" points to a track, that are kept in some way or another when saving (even only in the software's own file format), and allow the use of online routing instead of the offline one (but it is just to be complete, in fact i'm satisfied with offline routing) meet your philosophy ?

    I'm willing to help, fluent in c++ but less in Qt. And I discovered the source three days ago ;)

  19. Christian Eichler

    To be honest, apart from ability to recover the control points after a save, drawing a track behaves identically if you use an offline router. Imho, this is not a feature of the route - this is clearly missing for tracks. As soon as you know the control points you can simply remove all other points and do the routing again (this already works if you draw a track without saving).

    -> "Control points" already exist (the square trackpoints red line in the picture below), the small black points are points generated by the router.


    Nevertheless I can't really estimate the amount of work required for making tracks behaving properly (p.x. control points).

    Talking about my philosophy: At the end of the day I do not think that we should never ever include a conversion from route to track. I'm using offline routing too, so I don't really care about online routing.

    If you have some .gpx files containing routes, and you want to convert them to tracks to do whatever, then implementing that conversion is a good idea (imho).

    But I do not think that this is a good way to solve inconsistencies / flaws in QMS by building around them. Routes (from a .gpx technical view) seem to be pretty useless, as their extended format is unknown, so they are quite limited, why would you draw them?

    To sum up: I do not see any reason why QMS should not contain both solutions - but I refrain from implementing workarounds.

    Edit: If you just started looking at the code, implementing a conversion from route to track is (I hope) less error prone (as you do not need to modify any core datastructures). However fixing the tracks is something that should to be addressed in the future (in general, not especially by you).

  20. Michel Durand

    To say things with my words :

    • "save control points to tracks" is what I need, "route to track" is only a (poor) workaround


    • "route to track" still has some usecases even if I have "save control points to tracks", but priority is much lower

    But "save control points to tracks" is much more complex because it implies lots of changes in the way data is stored.

  21. Christian Eichler

    The main work will not be the "save control points to tracks" part, but the management around that - you will need to add features such as

    • Do routing over selected points
    • Remove all non-control-points
    • maybe: Convert (some of the) calculated points to "Control" points

    This will be - with no doubt - more work than a plain "convert route to track", but it is quite powerfull and in the most cases more convenient (less indirections). I do not think you will need to do huge changes to the datastructure - you can save the property "is a controll point" in one bit (read: "a flag").

    The priority of all these changes is already quite low - this issue is half a year old and "nothing" happened yet.

    If you want to do your first contribution to QMS: Try to start small - otherwise you might end up frustrated, especially if you are not familiar with QT. Maybe do some testing and fix a minor bug.

  22. kiozen

    I really do quite some tour planning with QMS and never experienced all these "short comings". Anyway, my goal is to keep QMS a simple and maintainable program. Features have to fit together and offer simple primitives to get every job done. Not just a special use case to scratch the itches of a few users. In addition to that the GPX definition and how it is commonly understood by other applications and devices is another constrain that has to be taken into account.

    That said, GPX does not really know the idea of control points. Nor does other software or other devices. We could use segments. But other applications and devices have complete different ideas about what a segment is about. For example TwoNav will interpret it as "legs" which is kind of a stage of a tour. If you use a control point to force a certain route, this will result into another leg when using TwoNav devices.

    Anyway as said I have done a lot of tour planning. Usually I create a very coarse track by selecting just a few intermediate points. Next I check the track and fine tune it by deleting ranges of points and forcing an alternative track by setting an intermediate point. Sometimes there is a bug in OSM and ways are not connected. This will result into a very peculiar track. In that case I draw the part of the track manually. It's really easy and much more convenient than keeping a route and track in sync. I may remind you that in QLGT it was kind of that. To edit tracks or routes you had to convert them to distance overlays and back. Everyone was complaining: Why can't I edit the stuff directly. Converting sucks. Yes I agree. Editing one kind of an element and converting it into the other type of element you really want to use sucks. And that is why we won't do that mistake a second time.

  23. eric bechet

    Kiozen, we're not from the same planet ;) I never meant converting and delete original data ... but keep the original data as neat and lean way of representing a series of forced points of passage and convert only the result of a routing - thus enhancing the ease of use. This goal may be moot for you, but I don't think it is general. For sure, if you oppose to every attempt to things for which you don't see any use, it will die. But you know, I can live with that !

    Christian, I agree. The "save control points to tracks" is the right thing to do. "convert to track" (sorry, "copy to track") would have been simpler and brings the same features but I do understand it is out of scope after discussing with you guys.

    Shall I open a new issue for "save control points to tracks" ?

  24. kiozen

    No worries, I understand very well what you want to do. And I know that planning routes for recreative purposes is an iterative task. As a consequence you will have to export a route several times. If you forget you will start with a bad track. And if you come to the point where routing data is bad you will see that editing the track is much easier than placing a bulk of route points. So probably once we implement route->track conversion the next one will ask for track->route conversion. Which is quite complicated.

    I see a certain chance to preserve the control points. As each track point has a flag field that, so far, does not upset other devices or applications, we could mark these points. However this will change the behavior of the track edit mode. There are two aspects. The one is planning a tour. The other one is spoofing track recordings (a task I do not value very highly, but users stubbornly insist on it, How comes.... ). While planning a tour I want to have these control points. When spoofing a track I want to move points without adding control points. As long as we do not have focus-follow-mind it will be very hard to set up rules for introducing control points that are easy to understand, user friendly and applicable for all situations.

    Anyway I would advise to make your hands dirty. And if you end up with something really usable you can create a pull request for review. Please start with reading these Wiki articles:

    The classes to look for are CGisItemRte and CGisItemTrk. They can be found in their sub-folders below src/gis/.

  25. Christian Eichler

    Even though this might not really belong here, but as we were talking about shortcomings: At this point online routing is mostly useless, as the only way you can use it (as far as I know) is "Calculate Route". And routes are - that is the main point in this discussion - a dead end.

  26. kiozen

    And keep in mind that MapQuest is limited to 15000 request a month. I frequently get mails form MapQuest that the limit is close to be reached. Using it for track completion would exceed the quota very fast for sure.

  27. wrosner

    I'd like to add some motivation to this thread with my use case: Motorcycle navigation

    I dropped into QMS by searching google for "wine BaseCamp" and I am really impressed by the first tests. However, my last google search was "QMapShack track to route", which sent me on this page. "wontfix" was not the message I hoped to find.

    Just a fourtnight ago, I attached my car-navi (Garmin nüvi 154) to my bike to learn after some 1000 km tour expeience the pro's and con's of routes and tracks. On the motorbike, you will desperateley appreciate the route function of your device with fast navigation instructions, e.g. when you cross a city or some area of heavy traffic or high speed motorway. On the other hand, you will have off-road-like elements in your (presumably preplanned) tour, for which a track would be the preferrable data structure. Also tracks are the mean of exchange for offline routings, published tours on the web and dowloads of tracklogs from the device.

    However, at least my Garmin nüvi 154 does not even support the display of uploaded tracks - at least not in a documented way. I ordered a nüvi now (special motorbike edition from Garmin) which I hope can manage tracks, but we'll see whether the ad promises are kept.

    Nevertheless, when I leave my preplanned tour, e.g.

    • because of traffic jams or construction sites
    • different starting points in case of foreign sourced tours
    • just because the other way looked nice or had a pizza on the way

    the re-routing funcion in the device is what I want to find back to my track. But for that purpose, I need the routing information from the planning stage available on my device.

    When I'm "back on (preplanned)" track, I'd prefer both information:

    • The route with the real-time navigation instruction and flexible (but sometimes unwanted "creative") adaptation to changes
    • The track with the uncompromitted plan.

    When I go offroad (or close to that, depending on the machine), the route becomes useless and only the track will help me.

    Back home again, I might download my trip log (which is a track), convert it back to a route and apply some changes, like nice points I have missed, to visit the same area again.

    If the zümo supports tracks and I cannot manage to convert between tracks and routes in QMS, I have to fall back to wine and BaseCamp (sad to say) or even use my WIN-Laptop for tour planning.

    However, my Idea for a workaround might be an external tool for conversion between tracks and routes.

    The project style data handling of OMS should make it easy to provide import and export from and to gpx for some command line tools, which are plenty under linux. This approach might help the minority of users (like motorcyclists, which are not always best friends of bicyclists and walkers, especially when they go offroad, I know ;-) ) without any interference in the core design of QMS

    Does anybody have any Idea where to look for? My first place will be the routino docu, because I think you will need access to the road graph for any reasonable work on routes. I'll keep you informed on my findings.

  28. kiozen

    First, I hope you are aware that there is no way to transfer a pre-calculated route 1:1 to any GPS device. The GPX specification simply lacks the necessary elements. And the extensions invented by Garmin are partly hashed and can't be reverse engineered.

    If you transfer a route to a Garmin the start and end point is exchanged. And intermediate POIs. But not the many dots that form the actual street polygons. Nor the instructions. Short: all points of a QMapShack route that are drawn as large, red circle are copied to the device as a route. Nothing else.

    That said I fear you will be quite disappointed about the tour planning capabilities when it comes to street navigation. As routes have very little use because of that, no one of the core developers has volunteered to pic up the topic. And that is why it is a won't fix. However if someone else wants to pic it up he/she is welcome to do so.

    I see two major topics here:

    Route to track: That is fairly easy. But drawing a track right away from the spot is easier.

    Track to route: Much harder if you do not want to do it the stupid way converting every track point into an intermediate POI. That will exceed the maximum of the allowed POIs (for Garmin this is something like 50-250) very fast. Therefor it needs some clever algorithm to reduce the points.

    Anyway that has to be solved by those really in need of such a feature.

  29. wrosner

    I found some command line tools promising to do the job, including our GPS swiss army knife: []

    Introductory usage examples for conversion in both directions you find here: [] []

    There are also a number of online tools, e.g.

    The last one offers a bunch of conversion options. So, this would be the first choice for further scrutiny.

    I also encountered an in-depth fourm thread on the issue in an offroad-motorcycle forum: [] I start with a route and end up with a track. A route is my intended path of travel, the track is my actual path of travel.

    [] A track is just connect-the-dots for the points in the list, no calculations. (...) In the case of route there are tons of details put into the map that allow the GPS to calculate how to get from point to point on known roads.

    So let me try to clearify:

    • Tracks and routes resemble different stages in the planning process.
    • Routes are closer to the intention of the driver, in the earlier planning stage.
    • The route only gets its full meaning in combination with the map.
    • Tracks are closer to reality than to intention. They typically are generated either by real trip recording, or by merging the intention of the driver with the limits of reality - resembled by the map objects aka "roads" - in the routing process.
    • Tracks require no further data for interpretation - they are standalone self-confided geospatial objects. This makes them the preferred format for publishing and exchange of tour data.

    Exclusive discussion about "track or route" is - like exclusive discussion about high or low zoom level - rightway bullshit. In the tour planning process, you need both, and you would like to switch back and forth. When it comes to motorcycling, the process of plan revision happens both on tour preparation - on the PC software - and on tour replanning during the ride - on the device - often within the range of seconds and under heavy traffic conditions.

    Having said that, we follow that any track <-> route conversion without a map can only be a crutch. Therefore I did not follow the Links given above - I just kept them for curiosity and reference. Garmins BaseCamp e.g. requires the device connected for the conversion track->route and the process takes ages. I conclude that they access the map on the device for the process.

    While it might be possible to transfer routes between different maps (in the end, all maps are supposed to resemble the same realitiy on the planet) there are ample of warnings and bad experience of weird navigation artefacts. To avoid this, we need the same map for PC tour planning, track<->route conversion and for real-time replanning on the device. Using OSM for all, we don't require the device connected, because we don't have to fear that somebody steals our map in case we store it on the PC, as it looks in the Garmin case.

    I assume that for a reasonable tour planning environment with QMS, you will have routino offline routing installed - based on some reasonable OSM source. So this is the natural place to look for hooks to perform manipulations requiring any routing process.

  30. wrosner

    I agree with kiozen:

    • Route to track: That is fairly easy. But drawing a track right away from the spot is easier.
    • Track to route: Much harder if you do not want to do it the stupid way

    route->track: Maybe the whole issue just comes from my bad experience with nüvi series not willing to use tracks at all. Therefore, I preferred to keep all my planning in the form of routes, not tracks. I also suppose that the track format of QMS resembles some kind of both worlds: It appears to keep the waypoints from the routing process. In my crude hack tests (post to follow) I learned that routino outputs its tracks in the form of track segments.

    One of the main points of critics in the above mentioned motorcycle thread was the behavior when leaving a track: The device navigated on some arbitrary tour right to the closer endpoint of the whole track. This is definitely not what I want. I want to come back to my preplanned track as soon as possible. Maybe this works with the segmented tracks from QMS and the zumo series. I'll keep you informed.

    Nevertheless, even if it works with the segmented tracks as generated by QMS, this still leaves the task of importing unstructured breadcrumb tracks, e.g. from recorded tours or from third party sources. Usually one will use them as a template for further modification in the tour planning.

    The cumbersome way is to display the import and then to put manually as many dots on a new track/route until both show a reasonable fit. I have tried the track->route conversion in BaseCamp, and I definitely learned that this feature consideraly speeds up and improves the process of replanning recorded / imported / third party routes.

    I don't want to focus on the format details - this is handywork, in the simple case delegated to tools like gps babel. The challenge is on the logical approach to reduce the number of points in the track->route conversion close to a minimum but sufficient set. Any surplus waypoint not only costs memory (which is peanuts thanks to Moore's law), but hinders the process of replanning routes.

    The task actually boils down to extract: "what might the planner have wanted". Sounds like artificial intelligence, so we will try to avoid to reinvent the wheel, but to find a capable tool and build an interface.

    I see 3 different approaches:

    The last approach is the intelligent one I expect, and I think this is what BaseCamp does. I hope to extract from routino at least the intersection of roads, which should be resembled by some kind of nodes, interconnecting graphs.

    Maybe, in a second step, we can try to delete some of those intersections, too, and test whether the route changes. Only points that change the route upon removal are kept. This sounds tedious, but BaseMap takes half an hour for converting 30 km country side track. Maybe because it follws right this procedure?

  31. wrosner

    Route to track: That is fairly easy , so this what I tried first. Here is a crude hack from last night:

    # $debug=1;
    $infile  = "input-route.gpx";
    $outfile = "output-track.gpx";
    $gpsbabel=`which gpsbabel`;
    chomp $gpsbabel;
    $routino = `which routino-router`;  # for debian jessie
    chomp $routino ;
    # read the waypoints comprising the coordinates
    # gpsbabel -i gpx -o csv -f input-route.gpx -F -
    $cmd  = $gpsbabel;
    $cmd .= " -i gpx -o csv";
    $cmd .= " -f " ;
    $cmd .= $infile ;
    $cmd .= " -F -" ;       # write to stdout
    # prepare routino command head
    # see
    $cmd2  = $routino ;
    $cmd2  .= " --dir=";
    $cmd2  .= "/home/wrosner/tracks/qMapShack-Karten/routino-DB";
    $cmd2  .= " --prefix=";
    $cmd2  .= "Europe";
    $cmd2  .= " --output-gpx-track " ;
    $cmd2  .= " --quiet";
    $cmd2  .= " --output-stdout";
    if ($debug) {
            print $cmd ;
            print "\n" ;
    } else {                # die "todo####" ; }
      # pipe gpsbabel output to filehandle $FH   
      open (my $FH, '-|', $cmd) or die $!;
      my $i = 0;    # we need numbered points
      # parse the gpsbabel output line by line
      while (my $line = <$FH>) {
        if ($i++ > 99) { die "not more than 99 waypoints allowed"; }
        if ($debug) { print $line; }
        my ($lat, $lon, $label) = split(', ', $line, 3);
        if ($debug) { printf ("~~ %s ~~ %s ~~ %s ~~", $lat, $lon, $label ); }
        if ($debug) { print "\n" ;  }
        # append point to routino command
        $cmd2 .= sprintf(" --lon%i=%s --lat%i=%s", $i, $lon, $i, $lat);
    #  write stdout to file
    $cmd2 .= " > " . $outfile ;
    $debug = 1 ;
    if ($debug) { print $cmd2; }
    if ($debug) { print "\n" ; }
    system $cmd2;

    I use a route which I planned within QMS:


    I copied it into a new gpx project and stored it.

    When I open the exported input-route.gpx in Marble, I see the waypoints connected by straight lines, since marble does not perform routing.


    Using gpsbabel, you can extract the coordinates in comma separated format like this:

     gpsbabel -i gpx -o csv -f input-route.gpx -F -
    50.02573, 12.32633, RPT001
    50.06275, 12.34094, RPT002
    50.06490, 12.33408, RPT003
    50.04607, 12.39174, RPT019
    50.05151, 12.35732, RPT020
    50.02573, 12.32616, RPT021

    The perl scipt above does right this and parses the output to regain the lan/lot coordinate pairs. With this, it assembles a routino command line call, which looks like this

    /usr/bin/routino-router --dir=/home/wrosner/tracks/qMapShack-Karten/routino-DB --prefix=Europe --output-gpx-track  --quiet --output-stdout --lon1=12.32633 --lat1=50.02573 --lon2=12.34094 --lat2=50.06275 
     --lon21=12.32616 --lat21=50.02573 > output-track.gpx

    When I open the generated output-track.gpx in Marble, I see right the same routed track as in QMS - including some routing artefacts.


    Reloading output-track.gpx in QMS, both pathways match exactly. This is precisely what I hoped to get.

    This is a snippet from input-route.gpx

      <rtept lat="50.02572686" lon="12.32633422">
      <rtept lat="50.06274615" lon="12.34094407">

    and this from output-track.gpx

    <trkpt lat="50.064612" lon="12.334619"/>
    <trkpt lat="50.064860" lon="12.334032"/>
    <trkpt lat="50.064860" lon="12.334032"/>
    <trkpt lat="50.065108" lon="12.333445"/>
    <trkpt lat="50.066125" lon="12.332542"/>
    <trkpt lat="50.066125" lon="12.332542"/>
    <trkpt lat="50.066555" lon="12.332160"/>
    <trkpt lat="50.068975" lon="12.330768"/>

    In the last snippet, we see the tracksegments (<trkseg> tag) I mentioned above. On a first glance, it appears, that start and end of those tracksegments lie close to the waypoints of input-route.gpx, but do not match exactly. So, this format is a way to logically keep both the waypoint information from the routing process as well as detailed track information.

    Fine, and a great idea, but I'm afraid not that what we get from imported breadcrumb tracks.

    And is it standard for routing devices to utilize this information upon rerouting on the fly? Let's see what the zumo does with this segments...

    Of course, this is just a crude workaround to gain test data and a proof of concept. I am quite sure that QMS internally follows right this procedure every time you hit a road when interactively moving a track/route point. And presumably, it uses the routino API as opposed to the tedious command line detour which I used her.

    So, to be honest, I don't see that big issue in implementing this route -> track part of the job into QMS, if we only could motivate the skilled developers to do so. Maybe, we invite them to a nice trip .... I had one covering Saale, Werra, Fulda, Eder, Sieg, Rhein, Neckar, Jagst, Altmühl, Pegnitz the last weekend. All those scenic places of Germany.... Can we motivate bicyclists and wanderers that way ;-) ?

  32. kiozen

    Well, it's always up to the task you want to plan. I understand your need of a route when it comes to driving a motorbike. But as said this is a very weak spot of QMS. At least if you assume the same route to be calculated on the devices as in QMS/Routino/Mapquest et al. The only way to achieve that is to place enough intermediate POIs. Or to use Basecamp.

    Garmin dropped track navigation in favor of their automatic routing (reads: they want to sell maps). Today's Garmin map format has a lot more information regarding routing than known to the community and thus used by free OSM maps. And each router like Routino et al. is using different information and weights to calculate their routes. Thus even using OSM as a common database, routing algorithms will produce different results.

    Even Garmin does not manage to calculate the same route in their PC software as on the devices. This is due to quantification errors and probably small differences in the implementations. That is why they came up with those GPX extensions. These extensions define the polyline between two route points. And the intermediate points contain hash references for the instructions, too. This is working well if you use the very same map in Basecamp as on the device. The moment you use different versions of the map it might fail.

    You see routing is a very delicate topic. And all these tools you found will implement somehow a compromise. Most likely if you set 10-20 intermediate POIs the device should calculate a very similar route for a motor bike. In a forum there was a guy planning trips of up to 30-60km for longboards. The router he was using took paved roads and their slope into account, creating an ideal route for longboards. The route was exported as a track. However even Bascamp did not manage to create a 1:1 route from that track. He finally navigated by the track. For a longboard feasible, for a motor bike not.

    Btw. you can edit a track more or less the same as a route. Simply remove the section of the track you do not like and start to add a new trackpoint to the line. By that you can recycle old recordings. And you can copy sections of a track to combine them with other fragments. If it comes to creating tracks for planning QMS is quite flexible now.

  33. wrosner

    Just a sindeline question, regarding the merger of elevation. I see from my tracks, that some carry elvation, some do not.

    Maybe this depends on a DEM available at the time of track generation ? A track with missing elevation does not show up one even when displayed with DEM on.

    Anyway, do you know of any commandline tool to extract DEM from a file like eudem_dem_3035_europe.tif ? And maybe to merge them into an existing track? So I might include it into my hacked script above?


    maybe this is part of the answer: . []

    the output looks reasonable - at least in the first glance:

    ~/tracks/qMapShack-Karten/DEM/EU-DEM$ gdallocationinfo eudem_europe.vrt -wgs84 12.25 50.002
      Location: (99291P,120391L)
      Band 1:
        Value: 545.38623046875

    second update:

    just open a track in OMS, click edit and save it again seems to include DEM elevation. This will suffice for experimentation.

  34. kiozen

    It's a bit more complex. Have a look at the GPX specification

    A route is a <rte> tag enclosing a list of <rtept>. The route has to cross these intermediate POIs. Some Garmin units need the <rtept> coordinates also as waypoint (<wpt>). This is probably the reason why some GPX files have these waypoints.

    A track is a <trk> tag enclosing one or several <trkseg> tags. The <trkseg> tags have a list of <trkpt> tags with the actual track point coordinates. In fact the track definition is much more suitable to store a calculated route as the actual route definition is. That is one of the weak points of GPX. Blame it on Topografix.

    In QMapShack the red dots of a route are exported as <rtept>. I skip the madness with the waypoints.

    To simplify a track into a route you have to find enough intermediate points <rtept> that an algorithm can calculate a complete route to match the track. Plus it has to keep a limit because the devices can only handle a limited number of <rtept> per route.

    Elevation: This can be done by QMapShack. You have to download DEM data and add it to QMapShack. See for details. When done you can use a filter replace the track's elevation data with the loaded one. See

  35. wrosner

    Sorry for my sloppy reference to the gpx data structure. My intention was to focus on the essentials, which is the internal logic of the data.

    I am well aware of xml format basics, its inherent tree structure, the existence of schema definitions, and the requirement of strict adherence to the rules of construction for the "decoration"-items. I think I have a rough glance how to correctly parse and / or write xml. Have done such stuff ages ago in java environments.

    I know it is tedious handiwork, and I prefer to delegate this to well-tested tools (like gpsbabel) and libraries (I'm sure, you will know better). As always in IT projects, 95 % percent of the time budget go into the basic concept,. and the other 95 % go into the fix of the tedious details.

    But anyway, as long as the proof of concept and the general algorithm is not well established or not even clear, there is no point in investing in the second 95 % of the time budget.

  36. wrosner

    all right: second hack and proof of concept (so I hope) for a map based track generalisation.

    RTFM routino documentation:

    I tweaked above scipt a little bit

    • read from track instead from route (actually, gpsbabel does not mind, just adopt the file name)
    • produce all 5 output files available
    • stop reading after procession 60 points instead of throwing an error
    • pass --turn=0 to routino to avoid funny loop artefacts

    For the first test, I used a sample of a broadcrumb track i pulled from my Garmin nüvi /GPX/Archive directory.

    A first run of routino is used to analyze the track in reagard to the map. The number of points is actually increased from 60 to 98. No question, that the original track can be reestablished quite perfect, with slight adjustment to follow the "theoretical" track of the road.

    For a feeling what happens, I recomment a look to the file shortest-all.txt

    # Creator : Routino -
    # Source : Based on OpenStreetMap data from
    # License :
    #Latitude   Longitude       Node    Type    Segment Segment Total   Total   Speed   Bearing Highway
    #                                           Dist    Durat'n Dist    Durat'n                        
     51.192544     9.464219       -1    Waypt#1 0.000    0.00    0.00     0.0           
     51.192538     9.464228       -2    Waypt#2 0.001    0.00    0.00     0.0    80  136    Hegeweg (K 151)
     51.192538     9.464228       -3    Waypt#3 0.000    0.00    0.00     0.0    80  270    Hegeweg (K 151)
     51.192472     9.464327       -4    Waypt#4 0.010    0.01    0.01     0.0    80  136    Hegeweg (K 151)
     51.192413     9.464416       -5    Waypt#5 0.009    0.01    0.02     0.0    80  136    Hegeweg (K 151)
     51.191909     9.465178       -6    Waypt#6 0.077    0.06    0.10     0.1    80  136    Hegeweg (K 151)
     51.191307     9.466088 77945438*   Junct-  0.092    0.07    0.19     0.1    80  136    Hegeweg (K 151)
     51.190474     9.467342       -7    Waypt#7 0.127    0.10    0.32     0.2    80  136    Hegeweg (K 151)
     51.189949     9.468131 77945480    Inter   0.080    0.06    0.40     0.3    80  136    Hegeweg (K 151)
     51.189670     9.468448 77945488    Waypt#8 0.038    0.03    0.43     0.3    80  144    Hegeweg (K 151)
     51.189504     9.468531       -9    Waypt#9 0.019    0.01    0.45     0.3    80  162    Hegeweg (K 151)
     51.189324     9.468621      -10    Waypt#10    0.021    0.02    0.47     0.4    80  162    Hegeweg (K 151)
     51.189145     9.468710      -11    Waypt#11    0.020    0.02    0.49     0.4    80  162    Hegeweg (K 151)
     51.188971     9.468798 77945495    Waypt#12    0.020    0.02    0.51     0.4    80  162    Hegeweg (K 151)
     51.188602     9.468945 77945497*   Inter   0.042    0.03    0.56     0.4    80  165    Hegeweg (K 151)
     51.187877     9.469142      -13    Waypt#13    0.081    0.10    0.64     0.5    80  170    Hegeweg (K 151)
     51.187492     9.469247      -14    Waypt#14    0.043    0.05    0.68     0.6    80  170    Hegeweg (K 151)
     51.187403     9.469272 77945503    Waypt#15    0.010    0.01    0.69     0.6    80  170    Hegeweg (K 151)
     51.187283     9.469407      -16    Waypt#16    0.016    0.02    0.71     0.6    80  144    Hegeweg (K 151)
     51.187073     9.469642 77945512    Waypt#17    0.028    0.03    0.73     0.6    80  144    Hegeweg (K 151)
     51.186969     9.469685 77945515*   Waypt#18    0.011    0.01    0.74     0.6    80  165    Hegeweg (K 151)
     51.186897     9.469658      -19    Waypt#19    0.008    0.01    0.75     0.6    80  193    Brunslarer Straße (K 151)
     51.186842     9.469637 77945511    Waypt#20    0.006    0.01    0.76     0.6    80  193    Brunslarer Straße (K 151)
     51.186731     9.469511      -21    Waypt#21    0.015    0.02    0.77     0.7    80  215    Brunslarer Straße (K 151)
     51.186643     9.469409      -22    Waypt#22    0.012    0.01    0.79     0.7    80  215    Brunslarer Straße (K 151)
     51.186149     9.468844 77945496*   Waypt#23    0.067    0.08    0.85     0.8    80  215    Brunslarer Straße (K 151)
     51.185904     9.468631 77945492*   Junct-  0.031    0.04    0.88     0.8    80  208    Brunslarer Straße (K 151)
     51.185805     9.468533 77945489    Inter   0.012    0.01    0.90     0.8    80  211    Brunslarer Straße (K 151)
     51.185740     9.468411      -24    Waypt#24    0.011    0.01    0.91     0.8    80  230    Brunslarer Straße (K 151)
     51.185664     9.468266      -25    Waypt#25    0.013    0.02    0.92     0.8    80  230    Brunslarer Straße (K 151)
     51.185459     9.467875 77945476*   Junct-  0.035    0.04    0.96     0.9    80  230    Brunslarer Straße (K 151)
     51.185182     9.467100 77945463*   Junct-  0.061    0.07    1.02     0.9    80  240    Brunslarer Straße (K 151)
     51.185125     9.466934      -26    Waypt#26    0.013    0.02    1.03     1.0    80  241    Brunslarer Straße (K 151)
     51.185073     9.466782      -27    Waypt#27    0.012    0.01    1.04     1.0    80  241    Brunslarer Straße (K 151)
     51.184915     9.466324      -28    Waypt#28    0.036    0.04    1.08     1.0    80  241    Brunslarer Straße (K 151)
     51.184902     9.466286      -29    Waypt#29    0.003    0.00    1.08     1.0    80  241    Brunslarer Straße (K 151)
     51.184876     9.466209 77945442*   Junct-  0.006    0.01    1.09     1.0    80  241    Brunslarer Straße (K 151)
     51.184492     9.465856      -30    Waypt#30    0.049    0.06    1.14     1.1    80  209    Brunslarer Straße (K 151)
     51.184257     9.465639      -31    Waypt#31    0.030    0.04    1.17     1.1    80  209    Brunslarer Straße (K 151)
     51.184202     9.465589      -32    Waypt#32    0.007    0.01    1.17     1.1    80  209    Brunslarer Straße (K 151)
     51.184155     9.465546      -33    Waypt#33    0.006    0.01    1.18     1.1    80  209    Brunslarer Straße (K 151)
     51.183779     9.465199 77945409*   Junct-  0.048    0.06    1.23     1.2    80  209    Brunslarer Straße (K 151)
     51.183474     9.464867      -34    Waypt#34    0.040    0.05    1.27     1.2    80  214    Brunslarer Straße (K 151)
     51.183337     9.464717 77945398*   Junct-  0.018    0.02    1.28     1.3    80  214    Brunslarer Straße (K 151)
     51.183302     9.464682 77945397*   Junct-  0.004    0.00    1.29     1.3    80  212    Brunslarer Straße (K 151)
     51.182943     9.464304 77945389*   Junct-  0.047    0.06    1.33     1.3    80  213    Brunslarer Straße (K 151)
     51.182889     9.464250      -35    Waypt#35    0.007    0.01    1.34     1.3    80  212    Brunslarer Straße (K 151)
     51.182566     9.463927 77945380*   Junct-  0.042    0.05    1.38     1.4    80  212    Brunslarer Straße (K 151)
     51.182410     9.463677 77945374*   Inter   0.024    0.03    1.41     1.4    80  225    Brunslarer Straße (K 151)
     51.181929     9.462834      -36    Waypt#36    0.079    0.06    1.49     1.5    80  227    Brunslarer Straße (K 151)
     51.181856     9.462706 77945348    Inter   0.012    0.01    1.50     1.5    80  227    Brunslarer Straße (K 151)
     51.181615     9.462403      -37    Waypt#37    0.033    0.02    1.53     1.5    80  218    Brunslarer Straße (K 151)
     51.181491     9.462246 77945336    Waypt#38    0.017    0.01    1.55     1.5    80  218    Brunslarer Straße (K 151)
     51.180966     9.462022 77945329    Inter   0.060    0.05    1.61     1.6    80  194    Brunslarer Straße (K 151)
     51.180442     9.461868      -39    Waypt#39    0.059    0.04    1.67     1.6    80  190    Brunslarer Straße (K 151)
     51.179466     9.461581 77945323    Inter   0.110    0.08    1.78     1.7    80  190    Brunslarer Straße (K 151)
     51.178335     9.461440      -40    Waypt#40    0.125    0.09    1.90     1.8    80  184    Brunslarer Straße (K 151)
     51.178009     9.461399 77945320    Inter   0.036    0.03    1.94     1.8    80  184    Brunslarer Straße (K 151)
     51.176907     9.460708      -41    Waypt#41    0.131    0.10    2.07     1.9    80  201    Brunslarer Straße (K 151)
     51.176688     9.460571 77945307*   Junct-  0.026    0.02    2.10     1.9    80  201    Brunslarer Straße (K 151)
     51.176017     9.460045 77945299    Inter   0.083    0.06    2.18     2.0    80  206    Brunslarer Straße (K 151)
     51.175461     9.459435 77945285*   Junct-  0.075    0.06    2.25     2.0    80  214    Brunslarer Straße (K 151)
     51.175316     9.459277 77945281    Waypt#42    0.019    0.01    2.27     2.0    80  214    Brunslarer Straße (K 151)
     51.175193     9.459046      -43    Waypt#43    0.021    0.02    2.29     2.1    80  229    Brunslarer Straße (K 151)
     51.175075     9.458826      -44    Waypt#44    0.020    0.02    2.31     2.1    80  229    Brunslarer Straße (K 151)
     51.174800     9.458309 77945269    Inter   0.047    0.04    2.36     2.1    80  229    Brunslarer Straße (K 151)
     51.174025     9.456624      -45    Waypt#45    0.145    0.11    2.51     2.2    80  233    Brunslarer Straße (K 151)
     51.173362     9.455183 77483016    Inter   0.124    0.09    2.63     2.3    80  233    Brunslarer Straße (K 151)
     51.172807     9.453595      -46    Waypt#46    0.126    0.09    2.76     2.4    80  240    Brunslarer Straße (K 151)
     51.172763     9.453469 77482990    Inter   0.010    0.01    2.77     2.4    80  240    Brunslarer Straße (K 151)
     51.172363     9.451810 77482962    Junct-  0.124    0.09    2.89     2.5    80  248    Brunslarer Straße (K 151)
     51.172182     9.451117      -47    Waypt#47    0.052    0.04    2.94     2.5    80  247    Brunslarer Straße (K 151)
     51.172015     9.450478 77482934    Junct-  0.048    0.04    2.99     2.6    80  247    Brunslarer Straße (K 151)
     51.171513     9.449057 77482910    Inter   0.113    0.08    3.10     2.7    80  240    Brunslarer Straße (K 151)
     51.171227     9.448511      -48    Waypt#48    0.049    0.04    3.15     2.7    80  230    Brunslarer Straße (K 151)
     51.171169     9.448400 77482888    Inter   0.010    0.01    3.16     2.7    80  230    Brunslarer Straße (K 151)
     51.170720     9.447754 77482867*   Junct-  0.067    0.05    3.23     2.7    80  222    Brunslarer Straße (K 151)
     51.170304     9.447245      -49    Waypt#49    0.058    0.04    3.29     2.8    80  217    Ellenberger Straße (K 151)
     51.170153     9.447061 77482828    Waypt#50    0.021    0.02    3.31     2.8    80  217    Ellenberger Straße (K 151)
     51.170048     9.447013      -51    Waypt#51    0.012    0.01    3.32     2.8    80  195    Ellenberger Straße (K 151)
     51.169902     9.446947      -52    Waypt#52    0.016    0.01    3.34     2.8    80  195    Ellenberger Straße (K 151)
     51.169564     9.446793 77482817    Inter   0.039    0.03    3.38     2.9    80  195    Ellenberger Straße (K 151)
     51.168901     9.446666 77482815*   Waypt#53    0.074    0.06    3.45     2.9    80  186    Ellenberger Straße (K 151)
     51.167905     9.446395 77482800*   Waypt#54    0.110    0.08    3.56     3.0    80  189    Ellenberger Straße (K 151)
     51.167824     9.446367      -55    Waypt#55    0.009    0.01    3.57     3.0    48  192    Grüner Weg
     51.167670     9.446313 77482797*   Waypt#56    0.017    0.02    3.58     3.0    48  192    Grüner Weg
     51.167583     9.446313      -57    Waypt#57    0.009    0.01    3.59     3.0    48  180    Grüner Weg
     51.167670     9.446313 77482797*   Junct-  0.009    0.01    3.60     3.0    48  360    Grüner Weg
     51.167905     9.446395 77482800*   Junct   0.026    0.03    3.63     3.1    48   12    Grüner Weg
     51.167748     9.445884 77482783    Waypt#58    0.039    0.03    3.67     3.1    80  243    Ellenberger Straße (K 151)
     51.167651     9.445778      -59    Waypt#59    0.013    0.01    3.68     3.1    80  214    Ellenberger Straße (K 151)
     51.167577     9.445699      -60    Waypt#60    0.010    0.01    3.69     3.1    80  214    Ellenberger Straße (K 151)

    Obviously, all input points are kept as Waypt, and routing points are added. In the view of routino output description, I applied following filter rule:

    • discard all points not marked as supernode (*)
    • discard all points marked as Waypt
    • discard all points marked as Junct- (minor Junction)

    This leaves 3 (sic!) points out of 98. I also added first and last point from the total list. I haven't yet scripted this filtering, but manually passed the coordinates of this 5 points to routino and see what happens:

    The calculated track from the 5 points still matches the input of 60 Points quite perfect:


    While the blue line resembles the route over the 5 points, the slightly pale/red-brownish track is from routino output. The somewhat more reddish track is the input track.

    You have to zoom into an area including an obvious logging artefact to see the difference


    However, I am aware that the rude filter approach will not always work that way. Maybe that when I follow minor roads in town, I must not discard all minor junctions or nodes not super. Maybe, on the other hand, when we travel long distance on a major road, we might even discard junctions not marked as minor. And maybe, that if an input point is close to a node, it is still marked as Waypoint, but relevant for an unambigouous route definition.

    So we will require some kind of adaptive tuning of the filtering rules, based on tests, how many points we can discard without leaving the recorded road.

    This adaptive approach should also try to adjust the vehicle capability: It might well be that we enter roads that are not marked as such, so we have to switch to bicycle or pedestrian mode to access inferiror pathways that are not marked as available for e.g. motorcycle profiles. And if we get lost offroad, we have to supend the mapping process completely.

    Another issue that calls for an iterative apporach is a nasty "segmenteation fault" of routino. Using said test data, it occurs at 65+ input points, therefore the limit to 60, not to 99 as indicated by the manual. Presumably, this failure may depend on specific properties of the input data.

    Even without this fault, the nuber of input points for routino is limited to 99. So we have to cut the input into pieces and merge the final routes back anyway.

    So there is still a long way to go from here to yield intelligent map based track simplification fit for practical purposes.

  37. Michael Waldor

    Thank you also from my side - converting a route into a track now works fine.

    As usual new ideas come to my mind if using new functionality: The route does have turning information (aka "cue sheet"), the track does not, as there is no proper place within GPX for storage. But what if adding a new option into track conversion to automatically convert the routing points into new waypoints, name them with an english term describing roughly the direction (e.g. TurnLeft, Turn Right, ...) and store the full text (from routing) within the description field?

    Currently I use the following workflow to solve my "problem": 1. Create a set of waypoints at each turning point and name them manually (sic). 2. Convert that set (automatically) into a route. 3. Convert that route (automatically) into a track. 4. Upload that track onto my GPS device. The waypoints are necessary to get alarm beeps when reaching a waypoint. Sadly there is no alarm from routepoints or trackpoints.

    Editing such a waypoint/route/track combinatiop is somewhat uncomfortable. That's where my suggestion comes into play - I only have to edit the route, and everything else would be done automatically.

  38. Log in to comment