Support Export of GPX Files including Garmin's Route Extensions
Some (but not all) Garmin vehicle GPSs with recent firmware support importing a route with a predefined path between the route points. The intention of this is to allow routes to be created in Garmin's MapSource software without the GPS recalculating the route on import. For example, it was introduced in version 3.80 of the firmware for the Garmin Zumo 660.
I wrote a (rather crude) website a while ago that allows routes to be produced using Google Maps and exported in a format that can be used on these Garmin GPSs so that routes can be dragged around and customised rather than relying on the auto-routing. It was very simple to implement and seems to be quite popular judging from the number of "thanks" emails I get!
Is there any possibility that this could be added as an option to the GPX export dialog in Locus Pro? This would allow routes to be planned while on holiday and they could then be downloaded to the Garmin Zumo for the next day's riding. I tried using the track export from Locus but this doesn't work very well on the Garmin. Using the route export works, but produces a very large number of route points and, if a road is closed, you have to manually remove points from the list after getting back onto the right route - this is very painful.
To show how simple the format is, I've written a small python script that takes a Locus Pro exported track and converts it into the Garmin route format. This is available on bitbucket. It works well, but is a bit of a pain to use on an Android device.
I like this idea 
Hello Alan,
to allow me understand faster, may you please create for me a track exported from Locus and same track converted by your method? Thanks
Hello Alan,
to allow me understand faster, may you please create for me a track exported from Locus and same track converted by your method? Thanks
No problem at all. The comment box won't let me attach GPX files (it says "Incorrect file type"), so I've added them to the bitbucket repository:
Original exported file is here (note that waypoints in the file are ignored by my script - just the trk is used).
Converted file is here.
For a single track segment, it has two <rtept>s. The first one has its lat/lon set as the start of the track. It then has a block of <gpxx:rpt> points with each lat/lon in the track except the first and last one. The second <rtept> is the last point in the track. So the <gpxx:rpt> bits basically describes the path from the start to the end, but the only two actual waypoints in the path are the start and end of each segment.
----
Stepping back from the converter for a second, the ideal output (from my point of view) would be one rtept for each "control point" in the path, so if you create a route in Locus from (e.g.) "Town 1" to "Town 2" and then drag the mid-point such that it goes via "Village 1", you'd get three <rtept>s: "Town 1", "Village 1" and "Town 2" and the "Town 1" <rtept> would include lots of <gpxx:rpt>s describing the path from "Town 1" to "Village 1" and the "Village 1" <rtept> would include lots of <gpxx:rpt>s describing the path from "Village 1" to "Town 2".
That's what I would consider the ideal output, but if it just produces a single start and end <rtept> and a <gpxx:rpt> path in between, that would be okay.
No problem at all. The comment box won't let me attach GPX files (it says "Incorrect file type"), so I've added them to the bitbucket repository:
Original exported file is here (note that waypoints in the file are ignored by my script - just the trk is used).
Converted file is here.
For a single track segment, it has two <rtept>s. The first one has its lat/lon set as the start of the track. It then has a block of <gpxx:rpt> points with each lat/lon in the track except the first and last one. The second <rtept> is the last point in the track. So the <gpxx:rpt> bits basically describes the path from the start to the end, but the only two actual waypoints in the path are the start and end of each segment.
----
Stepping back from the converter for a second, the ideal output (from my point of view) would be one rtept for each "control point" in the path, so if you create a route in Locus from (e.g.) "Town 1" to "Town 2" and then drag the mid-point such that it goes via "Village 1", you'd get three <rtept>s: "Town 1", "Village 1" and "Town 2" and the "Town 1" <rtept> would include lots of <gpxx:rpt>s describing the path from "Town 1" to "Village 1" and the "Village 1" <rtept> would include lots of <gpxx:rpt>s describing the path from "Village 1" to "Town 2".
That's what I would consider the ideal output, but if it just produces a single start and end <rtept> and a <gpxx:rpt> path in between, that would be okay.
Thanks, understand.
Have to ask, isn't then better to use existing TCX export from Locus instead of this?
Thanks, understand.
Have to ask, isn't then better to use existing TCX export from Locus instead of this?
Hi Menion,
I must admit, I'd not come across the TCX format, but I'm not sure whether this will help: it looks like it is more orientated around running type GPSs rather than vehicle ones (the Zumo that I use is a motorcycle GPS; this is the reason I don't want to use Locus for the actual navigation: my android devices aren't waterproof!).
I don't have my Garmin with me at the moment, but I'll try exporting a TCX file and see whether it works with the Zumo. On page 27 of the Zumo 660 manual, there is a list of supported file types and TCX files aren't listed. Compare this with page 22 of the Edge 800 cycling GPS manual, which does list TCX files.
Thanks,
Al
Hi Menion,
I must admit, I'd not come across the TCX format, but I'm not sure whether this will help: it looks like it is more orientated around running type GPSs rather than vehicle ones (the Zumo that I use is a motorcycle GPS; this is the reason I don't want to use Locus for the actual navigation: my android devices aren't waterproof!).
I don't have my Garmin with me at the moment, but I'll try exporting a TCX file and see whether it works with the Zumo. On page 27 of the Zumo 660 manual, there is a list of supported file types and TCX files aren't listed. Compare this with page 22 of the Edge 800 cycling GPS manual, which does list TCX files.
Thanks,
Al
Hi Menion,
I've tested the TCX file on the Zumo 660 and can confirm that it isn't recognised. It doesn't appear to be compatible with this type of GPS.
Al
Hi Menion,
I've tested the TCX file on the Zumo 660 and can confirm that it isn't recognised. It doesn't appear to be compatible with this type of GPS.
Al
Good day Al,
I was thinking quite long about adding support for export format you use in some unobtrusive way, but I finally decided not to support it. I cannot say how much users finds such feature useful, but I'm worried that really low number. And for rest of them it will be just "another settings which make no sense and usage". So sorry. Declined
Good day Al,
I was thinking quite long about adding support for export format you use in some unobtrusive way, but I finally decided not to support it. I cannot say how much users finds such feature useful, but I'm worried that really low number. And for rest of them it will be just "another settings which make no sense and usage". So sorry. Declined
Hi Menion,
Okay, thanks for considering it anyway. Is this something that I could implement as a plugin (and if so, can you give me any pointers to help me get started)?
Thanks,
Al
Hi Menion,
Okay, thanks for considering it anyway. Is this something that I could implement as a plugin (and if so, can you give me any pointers to help me get started)?
Thanks,
Al
Hmm you mean creating an add-on for Locus?
Are you at least little bit skilled with Android SDK? If so, I see that extending tools that works with tracks (in similar way like with points - own button in point tools menu) is not currently possible, but it looks this won't be a complicated task. So if you want, I may quite quickly extend this in Locus API.
Hmm you mean creating an add-on for Locus?
Are you at least little bit skilled with Android SDK? If so, I see that extending tools that works with tracks (in similar way like with points - own button in point tools menu) is not currently possible, but it looks this won't be a complicated task. So if you want, I may quite quickly extend this in Locus API.
Yes, creating an add-on. I have written some very simple Android applications. I certainly wouldn't call myself skilled, but it feels like a simple task given an example add-on and a few pointers in the right direction. I'd certainly be open to having a go.
Yes, creating an add-on. I have written some very simple Android applications. I certainly wouldn't call myself skilled, but it feels like a simple task given an example add-on and a few pointers in the right direction. I'd certainly be open to having a go.
Fine, good to hear, then it should be possible solution. What you will need is Locus API and Locus Free/Pro application. Application is already on your device and how to install and use API is here: http://docs_old.locusmap.eu/doku.php?id=manual:locus_api , check section "Installation".
First required step is to be able to install "Locus API - Sample" on your device and correctly run it.
I've just updated API and also Locus itself so it will be possible to do some own actions with tracks, like for export custom export to GPX file. For this you will need a new versions which will be available probably next week.
Let me know if there will be any problem.
Fine, good to hear, then it should be possible solution. What you will need is Locus API and Locus Free/Pro application. Application is already on your device and how to install and use API is here: http://docs_old.locusmap.eu/doku.php?id=manual:locus_api , check section "Installation".
First required step is to be able to install "Locus API - Sample" on your device and correctly run it.
I've just updated API and also Locus itself so it will be possible to do some own actions with tracks, like for export custom export to GPX file. For this you will need a new versions which will be available probably next week.
Let me know if there will be any problem.
Hi Menion,
I've just followed the instructions on your installation page and I get this error in Android Studio:
It appears to be due to the diamond operator (ref: stackoverflow), but I'm not sure how to fix it. I'm sure I'm missing something obvious, but I couldn't see how to fix it (I tried to add the notes from the second answer on the stackoverflow page to the ext section in settings.gradle, but it rejected it). I've zipped up the project folder and shared it here.
Please can you offer any suggestions on what I'm doing wrong? I've added some installation details below, let me know if you need more information.
Thanks,
Al
Installation details:
Android Studio for Windows version 1.2.1.1 (fresh install today);
javac -version: javac 1.7.0_45
SDK platform versions installed: API10, API16, API17, API18, API19, API20, API22
Android SDK Build-tools installed: 19, 19.1, 21.1, 22.0.1
Android SDK Platform-tools installed: 22
Android SDK Tools installed: 24.2
Hi Menion,
I've just followed the instructions on your installation page and I get this error in Android Studio:
It appears to be due to the diamond operator (ref: stackoverflow), but I'm not sure how to fix it. I'm sure I'm missing something obvious, but I couldn't see how to fix it (I tried to add the notes from the second answer on the stackoverflow page to the ext section in settings.gradle, but it rejected it). I've zipped up the project folder and shared it here.
Please can you offer any suggestions on what I'm doing wrong? I've added some installation details below, let me know if you need more information.
Thanks,
Al
Installation details:
Android Studio for Windows version 1.2.1.1 (fresh install today);
javac -version: javac 1.7.0_45
SDK platform versions installed: API10, API16, API17, API18, API19, API20, API22
Android SDK Build-tools installed: 19, 19.1, 21.1, 22.0.1
Android SDK Platform-tools installed: 22
Android SDK Tools installed: 24.2
Good day Alan,
problem is probably that you use incorrect Java version in your Android Studio as "Compilation compatibility".
From link you mentioned, did you tried this suggestion? http://stackoverflow.com/a/19722777/836138
In Eclipse (used before Android Studio), was directly an settings where you choose which Java compatibility level should be used (so you should have installed Java 1.8, but you should enable compatibility to 1.6 etc. ). I expect something oike this in Android Studio as well, but I see no such settings, weird.
So please try add suggested lines, if it helps.
EDIT: ah back, I've have it ...
Tap on "file > project structure", here tap on all modules and check in Properties > Source and target compatibility. You will have probably somewhere 1.6 instead of 1.7
Good day Alan,
problem is probably that you use incorrect Java version in your Android Studio as "Compilation compatibility".
From link you mentioned, did you tried this suggestion? http://stackoverflow.com/a/19722777/836138
In Eclipse (used before Android Studio), was directly an settings where you choose which Java compatibility level should be used (so you should have installed Java 1.8, but you should enable compatibility to 1.6 etc. ). I expect something oike this in Android Studio as well, but I see no such settings, weird.
So please try add suggested lines, if it helps.
EDIT: ah back, I've have it ...
Tap on "file > project structure", here tap on all modules and check in Properties > Source and target compatibility. You will have probably somewhere 1.6 instead of 1.7
Hi Menion,
Yeap, that fixed it: thanks - the source and target compatibilities were all blank, so they probably defaulted to 1.6. I'll have a dig around the code and let you know if (or more likely: when) I have problems!
Thanks
Al
Hi Menion,
Yeap, that fixed it: thanks - the source and target compatibilities were all blank, so they probably defaulted to 1.6. I'll have a dig around the code and let you know if (or more likely: when) I have problems!
Thanks
Al
Hi Menion,
The one that was causing an issue was locus-api-android: interestingly, when I correct this in Android Studio, it adds the following lines to the bottom of the android block in build.gradle in the locusAPI_android folder:
Should these lines be added to the bitbucket repository?
Alan
Hi Menion,
The one that was causing an issue was locus-api-android: interestingly, when I correct this in Android Studio, it adds the following lines to the bottom of the android block in build.gradle in the locusAPI_android folder:
Should these lines be added to the bitbucket repository?
Alan
Ah thanks, weird I had no such issue in my Android Studio
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7
I'll add these parameters to API in next commit.
Ah thanks, weird I had no such issue in my Android Studio
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7
I'll add these parameters to API in next commit.
Hi Menion,
Just for information, I've implemented this and it seems to be working well based on the testing I've done so far. I'll plan a few more routes and test them and then I'll sort out things like a new icon and getting it on google play. Thanks for all your help.
Out of curiosity, what does the getBreaks() function in the Track object return? I had naïvely assumed that it would return the indices of the "control points" that been dragged around when planning the route, but then I realised that these don't seem to be stored in Locus so that's not possible.
Thanks,
Al
Hi Menion,
Just for information, I've implemented this and it seems to be working well based on the testing I've done so far. I'll plan a few more routes and test them and then I'll sort out things like a new icon and getting it on google play. Thanks for all your help.
Out of curiosity, what does the getBreaks() function in the Track object return? I had naïvely assumed that it would return the indices of the "control points" that been dragged around when planning the route, but then I realised that these don't seem to be stored in Locus so that's not possible.
Thanks,
Al
Glad to hear it!
breaks: imagine you record a track, when you have recorded 102 points, you press a pause button for a while. Later you press pause again to continue in recording. But on a map, you will also see that track line will be broke in the middle, right after point 102. And this "breaks" array contains indexes of points, after which should be a break. So in above example, there will be probably only one index with value "101".
Glad to hear it!
breaks: imagine you record a track, when you have recorded 102 points, you press a pause button for a while. Later you press pause again to continue in recording. But on a map, you will also see that track line will be broke in the middle, right after point 102. And this "breaks" array contains indexes of points, after which should be a break. So in above example, there will be probably only one index with value "101".
Ah, okay: that makes sense. I'll have a think about how best to handle them in the exporter, although in most cases I would expect that there would be no breaks as it would be a route planned with the (fabulous) "Add new route & measure" feature.
Ah, okay: that makes sense. I'll have a think about how best to handle them in the exporter, although in most cases I would expect that there would be no breaks as it would be a route planned with the (fabulous) "Add new route & measure" feature.
Understand. Anyway if you will wants to do something with it, try to export such track in Locus to GPX and you will see. GPX has useful tags <trkseg> (track segment) which may be simply used for this purpose.
Understand. Anyway if you will wants to do something with it, try to export such track in Locus to GPX and you will see. GPX has useful tags <trkseg> (track segment) which may be simply used for this purpose.
Yes: that makes sense for a track, but Garmin's "alternative" version of the GPX format doesn't really have anything like this. I imagine the best way would be to have a GPX with multiple <rte>s: one for each section.
Yes: that makes sense for a track, but Garmin's "alternative" version of the GPX format doesn't really have anything like this. I imagine the best way would be to have a GPX with multiple <rte>s: one for each section.
I notice in the latest changelog of Locus, it mentioned something about improving the generation of file-names based on the track name. Is this function available via the API?
At the moment, my plugin just cheats and names the file "garmin_"+date("yyyyMMdd-HHmmss")+".gpx", but it would be nice to use a similar naming scheme to Locus (maybe with a "garmin_" prefix or something. I wondered about implementing something myself, but baulked a little at the prospect of writing code to make filenames that would definitely be FAT suitable from a track name that could presumably be anything...
I notice in the latest changelog of Locus, it mentioned something about improving the generation of file-names based on the track name. Is this function available via the API?
At the moment, my plugin just cheats and names the file "garmin_"+date("yyyyMMdd-HHmmss")+".gpx", but it would be nice to use a similar naming scheme to Locus (maybe with a "garmin_" prefix or something. I wondered about implementing something myself, but baulked a little at the prospect of writing code to make filenames that would definitely be FAT suitable from a track name that could presumably be anything...
Replies have been locked on this page!