Another Erratic Routing Incident

[John S Parry]

@Herman-Veldhuizen I don't know where the cursor was approaching point (7). It's a very technical section of Mulholland Highway that demands 100% attention on the road. The hairpins of that section are incredibly demanding, made even more challenging with a 9% upwards grade. It's a Butler Maps G2 rated section that I would argue probably deserves the highest level G1.

To your point, HERE does seem to have oddities. Whatever the situation, the route developer should be alerted of potential problems before actually executing it. Being hit with strange behavior while on the route is absolutely the wrong time. Using the Garmin GPS, I absolutely know ahead of time if the unit will treat the route differently (at execution) than what I developed. I sometimes have to do more than one iteration of adjustment before finalizing the route but it's worth the effort.

[Herman Veldhuizen]

This issue would have been less of an issue if the app had a way to automatically skip waypoint(s) independent from how far the next waypoint is.

[Brian McG]

@John-S-Parry my tip would be not to place points on twisty sections of road because this is where the map data from the different map providers will differ the most
if you compare the maps from TomTom, OpenStreetMap & Here you will see that straight sections of road tend to be much more similar & accurate
plus having a point on the navigation device mid-corner is a distraction you don't need

[John S Parry]

@Brian-McG Good suggestion, and I agree. That's why in my second iteration, linked in post#4, I moved point#7 further up the road to the straight area where the map and the route line converged again. For good MRA practice, I'll definitely be more conscious of this in the future.

I'm more concerned that the MRA route line and HERE map are out of sync. I use other phone apps (inRoute and OsmAnd) and I've never an issue where I place a waypoint/marker along the middle of a road. It shouldn't matter. In fact, OsmAnd has a "snap" feature to ensure the route line is attached to the road. Back to MRA, I trusted that what is OK in Routeplanner will sync accurately to the Next App without issue. Clearly that isn't always the case.

Again, I get what happened. It's a HERE issue, and the MRA developers seem to wash their hands of anything happening at that layer. I understand they have enough on their plate having to chase endlessly evolving CarPlay/Android Auto issues. I'll leave them at peace....

[John S Parry]

As an aside here, you can see from my original post (#1) that the app tried to turn me around to go back to waypoint #7. I checked my Navigation Functional Settings, and "Skip waypoints automatically" is set on ON.

It's been a while since I've used the app, so my memory on details is fuzzy here, but should I have been directed back to waypoint #7 with this setting on? I remember simply continuing past waypoint #8 and the route resumed as normal. Any clarification is appreciated.

[Brian McG]

@John-S-Parry I would say you only see the issue on MRA because MRA allows for a large number of map overlays & 3 different route calculation algorithms
this allows users to use whichever navigation device they wish while still using the very intuitive & easy to use MRA web planner
this was how MRA began it was a multi-platform planner long before it got into being a navigator

how many other apps & navigation systems allow such a large variety of maps & route calculators

[John S Parry]

@brian-mcg I saw this issue on MRA because there is the discrepancy between the road layout on the HERE map and the actual location of the road itself. In the nutshell, there is an error in the road layout on the HERE map. With respect, the error on HERE has nothing to do with the overall architecture of the product. An error is an error, and I happened to run across it.

I agree with you that what makes MRA unique are the different Routeplanner base map options and overlays. Routeplanner in particular is an incredible product that I use for 90% of my desktop route creation. I occasionally still use Garmin Basecamp and inRoute for special case situations, but Routeplanner is definitely my go-to.

Back to this situation: in this case I was only using HERE. That was HERE on the Desktop synced to HERE on the app. There weren't any user related errors triggered by injecting other base maps into the equation. Nothing outside of HERE came into play.

The bottom line?? There was a map error and I didn't catch it. If I had interogated the route on my HERE map with OSM and Google overlays I probably would have caught the route-to-road discrepancy in that section with the waypoint. It's not something I normally do (again, I shouldn't have to) but I got bit will do the additional step in the future.

[Brian McG]

@John-S-Parry in the "Toolkit" menu the function "Compare route with" is very helpful when deciding where to place points

where the 3 route calculations (Here, TomTom & OSM) overlay each other, you can be pretty sure that is where the road really is, & regardless of which navigation system you use, you will cross/passover that point when actually riding your route

[John S Parry]

@Brian-McG Yes, the Toolkit compare is a handy function. For safety, you definitely want to place waypoints where the other base maps agree.

Having to worry about the accuracy of a base map (any map) is a new concept for me. I've developed hundreds of routes in Basecamp (HERE) and inRoute (Apple), executed on Garmin GPS units, and have never encountered this. I know -- different environments, different behaviors.

I don't plan to use the MRA Next app again anytime soon, so at this point it's a non-issue. As I type, I'm setting up a new Garmin Zumo XT3, and that's going to be my primary route execution layer. Like I have been doing with my Zumo XT, I'll execute routes developed in MRA using the OSM base map. I've been snake bit using MRA HERE too many times.

[John S Parry]

@Brian-McG I thought you might find this interesting. I got out to test executing the route using my new Garmin Zumo XT3. Like MRA at waypoint#7, the XT3 recognized that the actual road did not match the HERE generated route. Zumo XT's have an Off-Route Recalculation option that essentially stops routing until the route rejoins the actual road, which it did further up where the road straightened out. The route re-started automatically with no intervention required on my part.

At the same time (side-by-side), I executed the route using the MRA Phone app. I had been playing with Nav Functional settings on the app to try to correct the "turn around" behavior from my first attempt. I enabled the "Skip Waypoints automatically" hoping it would ignore WP#7 and continue onward to WP#8 as it normally would. Well, that didn't work like I thought it would. The skip didn't kick in immediately. It wasn't until I was almost on top of WP#8 before I got a message, and then when I passed WP#8, the app tried to turn me around back to it. It was getting unworkable, so I stopped the route on the app altogther.

I'm going to change things up on the app again to try to get a successful run through that segment:

1. Switch to "Offline Navigation" from Online -- I don't know if this will change any behavior, but it's worth it to see if anything changes.

2. "Skip Waypoints automatically" turned OFF -- Maybe a manual skip when the problem with WP#7 first appears will give me a clean path to waypoint#8.

3. "Automatic recalculations" -- I was considering turning that option ON, but my fear is that it will trigger MRA trying to turn me around. If all else fails, maybe I change that on a subsequent attempt.

When getting ready to start the route on the app, it's clear that that it knows ahead of time about the issue:

It looks like it has already decided to turn around at WP#7, and double back counterclockwise to the main road (Kanan Road) to reach WP#8. That's not what I want, but....