@Mzokk said:

The main reason I've ended up here is the disappointing software provided for the XT (Explore) by Garmin and the change to its routing algorithm which meant, that compared to the old devices, what you produced on Basecamp bears little relation to what you get on the XT unless you "pin" the route with lots of shaping points. I'm pretty happy with the MyRoute app routing program and navigation app with the exception of POI and track handling capabilities. But at least with phone based navigation you are not restricted to Garmin's poor software offering. A lesson I hope they learn before its too late.

Wow, that's quite a collection of devices. Very nice.

Overall, your reasoning is fair. I personally did not enable Explore for either my XT or XT3 due to the disaster it creates for most users. It does nothing for you unless you want to buy into Garmin being an ecosystem across its devices. "Pinning" lots of shaping points is something I'm used to anyway since I lead rides and distribute GPX files to the other riders. You never know the routing preferences set up on other devices, so overloading shaping points is an absolute requirement.

MRA Routeplanner is the best route creation SW out there. I'm OK with BC, and it's remarkably capable for what it is. But Web based technology makes BC largely obsolete. The MRA Phone navigation piece?? I've tried to like it, but it doesn't speak to me the way an XT device does. It's another subject, but for me, phone HW isn't built for reliability in hot climates. I live/ride in the USA southwest, where phone overheating while running navigation is almost guaranteed 3-4 months of the year. Aside from phone HW limitations, an XT device is more capable than phone navigation SW at many levels. Again, another subject. What struck me most when going from my XT to an XT3 are the improvements to 3D Terrain map. The rendering is eye popping. It's looks like viewing from a Drone when riding through mountains and canyons. It's hard going back to the XT much less the MRA phone map.

Having said all this, I get that we all have different criteria and therefore end up with different setups. And there is nothing wrong with that.

I agree completely. I think it's been a valuable learning experience for all of us that use MRA in conjunction with a Garmin device.

Anyhow with regard to Garmin devices one thing I will say "and why I keep my XT mounted as a backup" is that the hardware itself is well made robust and reliable. These are all mine since 2004 and they are all in working order and all have been through some horrendously wet weather. Its unlikely that any of us will have a functional phone for that long.

The main reason I've ended up here is the disappointing software provided for the XT (Explore) by Garmin and the change to its routing algorithm which meant, that compared to the old devices, what you produced on Basecamp bears little relation to what you get on the XT unless you "pin" the route with lots of shaping points. I'm pretty happy with the MyRoute app routing program and navigation app with the exception of POI and track handling capabilities. But at least with phone based navigation you are not restricted to Garmin's poor software offering. A lesson I hope they learn before its too late.

@Steve-Jarrell said:

Thanks very much for the update. You clearly showed the HUGE advantage that 1.2 has over 1.1. Quite simply the route is forced to follow the track.

It's been fun learning about 1.2, and understanding the pros/cons vs. 1.1

To your point, the advantages are many. Developing a route using MRA Routeplanner, and literally being guaranteed that it will import as designed into an XT device is gold. Much has been said about the Sync function in MRA providing WYSIWYG on the app. But that's not 100% true. Depending on off-line or on-line execution in the app, the route can recalculate differently. Ask me how I know.

If there is a notable downside to 1.2, it's that you no longer have shaping waypoints available for skipping during route execution. It seems many here are constantly skipping to change the original route during execution. And there are many posts about how users get in trouble using that function. It's not a downside for me personally, but for others.....

The other issue I've encountered is that 1.2 doesn't seem to be supported in Basecamp. Meaning, if I create a 1.2 GPX and import it into BC, it gets munched up. At least that was my early experience. I'll have to go back and try it again to be 100% sure.

Otherwise, 1.2 ahead....

@Mzokk said:

I had a look at the setup of my XT as stated earlier I haven't used it for actual navigation for over a year now preferring instead to use my phone connected to my Africa Twin's built in screen.

First of all, I wish for your eye procedure to go well.

After completing the XT 1.2 off-route recalculation and being returned to the route, I decided to go off-route further ahead, but this time chose not to recalculate when prompted, which triggered the route to pause. After meandering around for a couple of miles, I manually re-entered the route line further ahead and my XT route came back to life. This is my normal method for handling off-route situations.

Then I hit the section of the route with the twisty section where HERE maps the road incorrectly. Because 1.2 is essentially following the Track of the MRA developed route, there was no alert for divergence. On the XT, it showed me riding the Track line where the road actually exists and then showed where the Track/Route converged up ahead. No drama, and no intervention. It's very slick.

Using 1.1 for this route in previous tests, this triggered an off-route alert that completely tripped up the MRA phone app running in parallel to my Garmin. The app tried to recalculate to the next waypoint but ended up in a loop where it was constantly trying to reroute me backwards. I had to stop and restart the app for it to continue.

When stuff like this happens, it just reinforces to me that the app is not yet ready for prime time. I admire the tenacity of the MRA Development team constantly chasing down errors and putting out fires, but it never seems to end. I'd like to feel that I have the option of using the phone app instead of my Garmin, but the confidence simply isn't there. I sincerely hope genuine app stability will somehow be achieved in the future.

I tend to navigate in the opposite sort of way where I seek out the backroads and try to avoid the main roads and towns as much as possible. There's nothing I like more than riding up a road with grass growing up the Middle.

I had a look at the setup of my XT as stated earlier I haven't used it for actual navigation for over a year now preferring instead to use my phone connected to my Africa Twin's built in screen. The only thing that I can see that might have messed up the behaviour of the unit on test was the OSM mapping of Ireland I have on an SD card in the machine. This shouldn't mess up the rerouting if its disabled as it was on my XT but I think it should be eliminated from the inquiries.

I'll delete the mapping from the SD card and have a go again with GPX 1.2. Unfortunately that might be a few weeks away as I go next week to have a cataract removed and will be off the road.....for everyone's safety

I had another go at simulating the route but obviously you can't simulate going off route just adding an element to the route before the first turn. As expected GPX 1.2 routed past the new addition directly to the next via point.

Whereas the GPX1.1 version of the file was able to deal with it.

Thanks for checking that John. I look forward to having another go minus the OSM maps on the card......and when I'm safe to be let out!!

@Mzokk said:

That would be brilliant. In my case it was trying to route me half way round the world to get back to the next via point when I didn't take the first turn.

I got out today and tested 1.2 off-route recalculation with my older Zumo XT unit.

I found the behavior to be the same as what I experienced with my XT3. When I turned left on a side road from my main road route, the XT almost immediately recognized Off-Route, and prompted me for action. I pressed re-calculate, and the XT immediately tried to turn me around through a looping side street. I continued, and then the XT tried to get me to do a U-Turn. The XT was like a Pitbull on a bone.

I know how this story would continue, so I did a U-Turn and returned to the main road at the Off-Route entry point as directed, just like I did with the XT3. I get that this is just one scenario, and you may have encountered a different situation which triggered a different action.

@smfollen-0 said:

gpx 1.2 route with the user specified via points and the route point extensions matching the track points, will provide the same very accurate representation of the MRA generated route as long as it is not fully recalculated. Unlike a track, it can be amended, to some degree, to support a Closest Entry Point navigation [re]start or an off-route calculation to get back onto the route without triggering a full recalculation.

@smfollen-0 said:

gpx 1.2 route will be the least accurate if it is fully recalculated since only via points will be available to the routing calculation.

Your complete post above was a very good read. Well written. In particular, the two GPX 1.2 pieces I quoted are gold for anyone wanting to understand it's behavior. In the nutshell, if you can avoid doing anything that triggers a complete 1.2 recalculation, the route should be a complete representation of the MRA route. The major trigger I found for complete recalculation is adding a via point as part of "Search" or "Up Ahead". As you stated, only via points will then be available for routing calculations, and your route will probably look very different from what you intended. There might be other offending actions, but I haven't found them -- yet. In my testing, Closest Entry Point navigation restart or an off-route calculation to get back onto the route do not harm the integrity of the route. That helped cement for me the value of 1.2.

All my testing with 1.2 has been for testing/verification purposes only. I'm feeling good enough to give it a go on something more critical coming up.

With the current state of navigation, we can debate Here vs OSM, tracks vs routes, gpx 1.1 vs 1.2, etc.

There was a time when the world was flat and was lighted each day by Helios who drove a golden chariot across the sky from east to west. Later, the earth began to become round, although it wasn’t circumnavigated until Magellan sailed around it in the early 1500’s. Around the same time, Copernicus proposed that the sun was the center of the universe. Galileo Galilei advocated for Copernicus’ theory in the early 1600’s. That heresy caused him to spend his later years under house arrest. Back then, latitude could be determined from the stars if the night sky was clear but longitude was elusive until clockmaker John Harrison produced the marine chronometer in the mid 1700’s.

GPS didn't become operational until 1993 but wasn't available for civilian use in 1998.

Many of us, at least the older ones like me, used to find our way around with sometimes out of date paper maps.

Today we look at lines on a digital screen and think of them as physical roads. We look at a motorcycle icon on a SatNav and think of it as our current position. We have high expectations for modern electronics. In reality, none of it is exact, although most of it is close most of the time.

Below is a section of road according to a Here map (magenta line), and an OSM map (green line). I traveled that road tracking my position with a zumo XT2 (yellow line) and another GPS tracking device (blue line). Depending on tolerance, we might say that all four lines are “right”. We might also conclude that it is unclear whether any of them are “right”.

A SatNav calculates it position on a periodic (not continuous) basis from time signals sent by satellites. The number of dots on those lines depends on how frequently position is determined and recorded. More dots imply more precision, but that does not assure any greater accuracy. Under the best conditions, those positions are accurate within several feet (a few meters).

In some locations, these four lines might vary more significantly. The vast majority of the time, they are close enough to be useful. On the occasions when they vary enough to be confusing, I try to remind myself, if Magellan managed to figure it out, I probably can too.

Planning and then navigating with the same map, route preference and avoidance settings, and with software / devices using the same routing algorithms is, of course, most likely produce the most consistent results for us, but it’s not always that simple. For various reasons, one might want, for example, to plan with the MRA route planner and navigate with the Garmin zumo.

In the end, we each do what works best for us and adjust as we learn from our experience. There is no perfect answer that works for everyone every time.

A map is an attempt to project, onto a flat surface, the location of physical roads or paths that exist on a portion of the round earth. Modern maps are much better than the ones Magellan had, but they rarely perfect. They are often generated from multiple sources. A given source which is most accurate in one particular area might not be the most accurate in a different area. Here maps are based on multiple, licensed, professionally produced, and government maps. Garmin’s are supplemented with OSM map data [thus the inclusion of both copyright notices on the device info page of a zumo].

Zooming in on a digital map reveals that roads and paths are represented by straight lines.

Each end of each straight line is a point, although the points are typically not visible. It requires more points to represent a curved road and fewer points to represent a straight road. There are also points at intersections.

Separate from those, when we click on a map to specify our desired stops (via points) and and other points we’d like to pass thorough (shaping points) we create “route points". Routing algorithms use the map’s points at intersections to find the best path(s) between our specified route points. Once the route is determined, all of the map’s points along the route can be used to draw the route along the road or path.

If a track is generated from the route, all of the map’s points along the route become track points. If a gpx 1.2 route is generated, those same points become route point extensions (aka hidden or ghost points). Track points and route point extensions are the exact same points. They are formatted and treated differently however. Once generated, a track will never change. If a route is fully recalculated, its route point extensions are discarded – the route is re-calculated using only the available route points (via and, if available, shaping points).

As a result, after import to another device, an MRA exported:

• track, with its many track points, will provide a very accurate representation of the MRA generated route, but it is fixed in place.
• gpx 1.2 route with the user specified via points and the route point extensions matching the track points, will provide the same very accurate representation of the MRA generated route as long as it is not fully recalculated. Unlike a track, it can be amended, to some degree, to support a Closest Entry Point navigation [re]start or an off-route calculation to get back onto the route without triggering a full recalculation.
• gpx 1.1 route with the user specified via and [relatively few] shaping points, but without the benefit of the [many] route point extensions, contains a less accurate representation of the MRA generated route. It will always be subject to route calculation and variation wherever it is imported.
• gpx 1.2 route will be the least accurate if it is fully recalculated since only via points will be available to the routing calculation.

@Carl-Lee said:

@mzokk but I was wondering if, despite the break in the HERE mapping on MRA, the Zumo would have routed through it anyway. Can you remember if the break was also on the Zumo map? And maybe not such a stupid idea as OSM mapping is one of the detailed maps in the unit. How and why they are used, I do not know.

No the Zumo would not have routed through the gap. I was using Basecamp. The map on the unit and the computer were identical. The only way to get the Zumo to route past that section was to put the "Direct" section in.

@john-s-parry during my testing and actually using a GPX1.2 route on the XT2 with auto-recalculation left on, sometimes it requested a U-turn or two if I carried on my diversion before changing its mind and calculating a way to get me back on the route ahead. And sometimes it would just go straight for the up-ahead re-join. It may go for the quickest option and also take into account one-way streets etc.

The only avoid option I have in the Zumo is unpaved roads. Everything else allowed. I hope the XT result is the same but I'm a little dubious.

My XT has been collecting dust for the past 2-months, and it was dead when I brought it out this morning. It's charging now, and I'll do an XT 1.2 off-route test tomorrow and share what happens.

I understand that you have a different view of things with your route planning to accommodate optional loops and other anomalies. That's cool. But off-route recalculation with 1.2 does work if you understand how it works and the specific scenarios to avoid.

@Carl-Lee said:

@mzokk, I'm wondering if in your above example, the OSM maps would not have had the break in the road in the first place?

Hi Carl, that's exactly my point, the fault would not have been evident in OSM, BUT the Here maps were on the device so the route would have recalculated as the device would have seen the gap in the mapping and screwed up the route.

@John-S-Parry said:

Using a 1.2 GPX file would have avoided much of this drama, and it's one of the reasons I'm going to adopt 1.2 until something happens to convince me otherwise.

Unfortunately the XT units do not play nicely with GPX 1.2 unless you switch recalculation off. Its good that the XT2 and 3 handle this much better but as I said I just plan most of my Routes on MRA route planner (the USP for me is that it's easy to use on the road) and just use the navigation app now. That means its WYSIWYG and there is no requirement to account for the vagaries of the Zumo XT. By the way I still love my Zumo 390 and 340 as their routing algorithm matches Basecamp when the settings are aligned and they also work well with the MRA Route planner. Truth be told, if I'd kept using the old simple units I'd never been tempted to move to phone based navigation.

@John-S-Parry said:

@mzokk Interesting scenario that you outlined. I've experienced some really strange HERE routing behaviour (on both Routeplanner and BC) but a gap like you showed has never been one of them.

I reported this one and its now gone. I also had to report a similar one while planning a route in Scotland's central belt using minor roads to thread a route between Glasgow and Edinburgh, one in the Massif Central on the D62 in France and a couple local to me in Ireland. It appears that these faults occur at the edge of map tiles particularly where a road passes near to a river or railway line. I presume the process of linking the tiles is automated and the computing algorithm can get a bit confused. In Ireland, the most accurate maps are those produced by the Ordinance Survey and Google (I'd say they were on a par). OSM is next with Here maps the least accurate. That said, they are all very usable its just that you find anomalies and out of date bits from time to time as you do on paper maps.

To your point, if using MRA Routeplanner (OSM map), I would not have seen this HERE map gap, and I would have been surprised with a messed-up route calculation with a direct transfer to the Garmin GPS side.

Except that I've adopted a very specific process to avoid these kinds of inevitable surprises. When creating MRA 1.1 routes, my first step is to always import into Basecamp for HERE verification. It's much easier to analyze/diagnose strange situations in BC than to do the same in the XT. I know that the XT doesn't have the exact same Garmin calculation algorithms as BC, but they're close enough to catch many HERE errors.

So back to your scenario...... In BC, I'd quickly see what you outlined and conclude a HERE mapping error. I'd go back to Routeplanner, use the "Skip" function as you described, and perform the BC verification step again. When satisfied with the fix, I'd import the MRA GPX 1.1 file into my XT and verify after recalculation. All would be good, and life would continue.

Using a 1.2 GPX file would have avoided much of this drama, and it's one of the reasons I'm going to adopt 1.2 until something happens to convince me otherwise.

As a final note regarding RUT. Again, I don't dispute that the phenomena exists. But it's not something I've personally experienced. I've always thought that it must have something to do with geography/terrain differences across the planet. The US has a much different road infrastructure than Europe, so maybe that accounts for our respective different experiences.

My XT2 also has OSM as well as HERE maps in 'detailed maps' so perhaps not such a surprise. Live and learn but what to do now? MRA does state OSM is the default base map and I believe that is all you get on the free version.

@mzokk, I'm wondering if in your above example, the OSM maps would not have had the break in the road in the first place?

Road Closures GPX1.1 v GPX1.2

Another little simulation (Traffic enabled):

GPX1.1 with multiple shaping points navigates round the shown road closure and back onto the original track/route - not just to the next via point. Nice.

GPX1.2 - the mapping shows the closure and there is no route recalculation but then the XT2 totally ignores it and rides through it. To some, this may be preferable as you can then navigate your own way round. I've had to do this many times anyway, usually in parts of Europe where the closure wasn't notified and you're just left to figure your own way around with no diversion signs. So not a showstopper but not as good.

Once again I'm left to ponder which way to go on this.

Hi John you just keep doing what works for you, but for the potential benefit of others, let me outline a real worked scenario, such that if you used OSM for planning and Here for navigation on a Garmin device you would get unexpected results.

I was making some routes for trip to Spain a few years ago when I happened upon a wonky piece of Garmin "Here" mapping on Basecamp.

This is the offending bit of road. Tried to route past it and the route was doing a massive detour to get to the other side of the (non existent) gap!

Road looks absolutely fine on google street view.

To make the route run as intended you need to put a section of direct navigation in the route to cover the mapping defect.

If you were using MRA for route creation you'd achieve the same effect by using the little Skip Icon.

This allowed the route to be completed.

If you had used OSM to plan the route in this scenario then tried to run it on a Garmin Zumo you'd wonder why the massive detour. This isn't an isolated case I've found (and reported) several such breaks usually on minor roads, in Ireland, central Scotland and rural France.

With regards to the RUT behaviour. I've used Garmin GPS devices since buying a Streetpilot 2610 in 2004 and still run a Zumo 390 and 340 on my venerable BMW R1150GS. I never joined any navigation forums until my wife bought me a ZumoXT as a retirement present. I could not understand how routes I had run on previous devices were now doing very odd things including trying to take me back to previously passed or missed shaping or skipped, via points RUT behaviour. Why was this? Well Ireland is covered in lots of very narrow meandering single track roads, which are the sort I prefer to ride on. Because of this routes have to have lots of shaping points as with the more recent Garmin navigators you are constantly fighting the internal routing algorithm to get the Zumo's to navigate minor roads. In addition, many of my routes contain optional loops to allow for slower than intended progress, for whatever reason, which means that via points and shaping points are often skipped. If you navigate this way on a Zumo XT, without using saved routes and allowing route recalculation, you'd be surprised at how often RUT behaviour can be observed. The only cure for this is to stop and restart the route. This behaviour was never present in any of my previous Garmin GPS units. The XT also led me here and I don't use it for navigation anymore, only to display a track of the route to enable me to use custom proximity alerted POI's during "Free Rides" and as a backup should anything go wrong with the phone I use for navigation on my Honda's built in AA/CP screen. I use the navigation app.

I do like Open Street maps and have used them in Garmin devices in the past and if I'm using those I also use them for route planning. I also subscribe to OSMand+ and use it occasionally for motorcycling but mostly for hillwalking and cycling. What I do like about it for motorcycle navigation is that you can set a proximity value (I use 150ft) within which the track you are navigating will snap to the road. This makes it more fault tolerant of the mapping used to create the track in the first place. I don't like its handling of via points and map markers for motorcycling however.

With regard to navigation I didn't get my first GPS until I was 43, 22 years ago and that was a revelation having toured most of Europe with maps. I also acted as a Co-Driver/navigator for several years in my 20's doing mostly night time regularity rallies. But that was all analogue, maps, road books and stopwatches.

With respect, your response is filled with a lot of "ifs, and buts". I'm not challenging what you presented as anything other than real possibilities. What I am saying is that in my years of creating hundreds of routes using OSM for export to Garmin devices (XT, XT3) I have never encountered any of the behaviors you outlined. I wish I had so that I could pick your brain for further understanding.

I'm glad that you brought up the Zumo XT Forum. It's probably the best resource for learning everything XT out there. The main characters in the forum are incredibly knowledgeable. "jfheath" in particular has been very helpful in my XT learning journey. But even there, I sometimes scratch my head with some of the XT behaviors discussed. I have personally never experienced the infamous RUT behavior. That's over a 5-years period of continuous XT/XT3 route planning. Ironically, if you read through the forum, a couple of the regulars have sheepishly admitted they haven't experienced the behavior either. Again, this isn't questioning that it can happen, but it's clearly not a global pervasive problem.

Going back to HERE, I agree that in a perfect world that you would use the same maps for development that are used in execution. So within MRA, why not just use HERE?

If you didn't see my discussion on HERE map inaccuracies, start with the route below:

https://www.myrouteapp.com/route/open/14129162

Open this OSM route up, and compare with HERE. You'll quickly see that the HERE cartography has the road deviating in a completely wrong location. I can't imagine a more serious vendor map sin than not getting a road location right. Beyond this specific HERE snafu, there are several other MRA HERE flaws that I find unacceptable:

1. Too much of a lag time in recognizing closed roads that are now open.
2. Showing roads open that have been closed sometimes for years.
3. Calculating random route off/on deviations where the Freeway/Interstate continues straight, sometimes for hours.
4. I can go on, but I'll spare you.....

Given all this, for me, it's a matter of picking your poison. I can use HERE for development and know I'll get randomly tripped up, probably at the most inopportune time. Or instead use OSM, which has proven through extensive actual use to be reliable.

Just my thoughts on the matter.......

@John-S-Parry said:

@Marinus-van-Deudekom said:

This whole topic is about getting routes into Garmin devices. Garmin uses Here as road map. Its a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices.
Im certainly not stating that the Here map is perfect. Far from that BUT it's the map Garmin uses.
If you want to use OSM be my guest.
By the way my Garmin devices are all sold
Im a MRA RouteXpert so yes I'm promoting MRA. Is it perfect no but pretty damn near close and as far as I'm concerned the number 1 app to navigate with.

If "it's a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices", where is the documentation? Proven facts are usually outlined somewhere for public consumption. This is the second time you've made this assertion, but again provide no context to what "causes problems" means. We all want to learn, but simply throwing out assertions that fly in the face of what others have actually experienced is not helpful.

But I'll take a stab at what you're trying to communicate. If in Routeplanner you create a route using OSM or TomTom, and in that route you minimize the use of shaping points and instead allow OSM/TomTom to make route calculation decisions for you, problems may in fact occur on a Garmin. You're then allowing Garmin, which has different route calculation algorithms, to possibly choose different paths between Via Points. I'd argue that the problem is more with the route creator than with OSM/TomTom. If you're actually talking about something else, please bring some substance that would be helpful.

Interesting discussion so far. With regard to the point above I'd have to concur with @marinus-van-deudekom. If you use the OSM or Tom tom mapping on a Garmin Device using Here mapping you may get unexpected results. This is because the road lines are projected in slightly different ways depending on the map set.

.

This is not a good example, but you can see that the map road lines don't quite line up. This is a google maps underlay with Here (black), TomTom red, and OSM blue road lines. The divergence is not bad in this example but I have encountered bits of road where the divergence is 10-15M. This can cause a problem particularly if a waypoint is inadvertently placed on the opposite carriageway because of map differences, or occasionally the route might direct you down a track you don't want to be on as OSM and Here categorise what constitutes a "Road" slightly differently :D. or you might have the occasional turn up a sideroad that is unintended. These issues are not serious but could be irritating. Long story short you will get better results if you use the map set that matches the maps on your device.
When I used my Garmin devices for navigation I often used OSM maps to keep old discontinued units for which Garmin no longer produce mapping up to date, and to make maps for places like Canada and the US, for which I had no mapping.

A write up I did explaining this can be found here.

https://www.ukgser.com/community/threads/using-open-street-maps-on-old-and-new-garmin-devices.439311/

Finally I notices a post on FrankB's excellent trip planner tool. This is indeed good but its use is dependant on having access to a computer to turn the routes on a Zumo XT to saved routes. There is another way to do this on the device itself. I take no credit for this Oop North John on the Zumo website discovered this. Basically if you have an imported route and you want to make it into a saved route to avoid potential RUT issues do this.

1. Send the calculated route to the XT

   2. Open it up in the Trip Planner

   3. Select Go!

   4. Select the next via / way point, then Start

   5. Then go back into Trip Planner

   6. Select Saved trips

   7. Select My Active Route and Save it. Unfortunately the original name is lost, but c'est la vie

   8. Then select the trip you just saved in the Saved Trips area

Again interesting thread which hopefully we will all learn from. That said if MyRoute app POI track handling was more functional I'd have no use for my Garmin devices at all.

We're all learning constantly (otherwise we wouldn't be here!) and the knowledge that we gain from our collective experience and viewpoints benefits all of us!