Another Erratic Routing Incident
-
Update: I went back out today to see if I could repeat the behavior related to waypoint#7. I fired up the route and followed it without deviation. Just like I did the first time around.
And I got the exact same result. It's repeatable! MRA/HERE thought I had missed waypoint #7 (I didn't) and I was directed to turn around at Calamigos Rd to return.
In preparation for this expected outcome, I copied the route and moved #7 further up the road (closer to #8) to see if it would change HERE calculation behavior.
https://www.myrouteapp.com/route/open/13885843
I re-ran the modified route, the new #7 calculated correctly, and I reached #8 without incident.
This isn't the first time I've encountered this kind of behavior in MRA -- Both with the Routeplanner (using HERE as the base) and the phone app. I love MRA Routeplanner and will continue to use it with OSM as the base map. It's very stable. Since I mostly use Garmin GPS units for route execution, no problems. As far as the app, I'm out. I can't have this strange HERE behavior mess a route up. Especially when I'm leading a larger group ride. Hopefully, it can be dealt with at some future point.
-
The cause is the discrepancy between the road layout on the HERE map and the actual situation. There is an error in the road layout on the map. See screenshot. If you switch on the OSM or Google Maps overlay, you can see this. The waypoint #7 is in the middle of nowhere and cannot be reached by car or motorcycle.
-
@reinhard-32 Yes, I suspected it had something to do with the placement of waypoint #7 in the curvy/technical section of Mulholland Highway. I didn't take the rigorous investigative step you presented to compare against the other map overlays or use the Compare option in Toolkit. It confirms why moving #7 to a section where HERE is in sync with the actual road fixes the problem. Thanks.
It's ironic that all the maps except HERE are in sync with the actual road layout. Should I be surprised?
I'm not an expert in the internal workings of MRA or HERE. But intuitively, it seems that if HERE in Routeplanner thinks the placement of #7 is OK, that HERE at calculation time in the App would also be OK with the placement. That's obviously not the case. My belief as a user is that I should not have to be concerned with inner workings at this level, but....
Moving forward, one option (during route development) is to always compare to the other overlays and never place a HERE waypoint where there is a map discrepancy. That could work in the majority of cases, but what if it doesn't? There may be situations where a waypoint is needed, but I don't have the option of simply relocating it further up the road. Since I have to use HERE for any route executed within the App, what then?
This is my dilemma and frustration. Some might say "I never have this problem", which might be true. However, many of the rural areas of the mountainous western US present unique challenges. My solution in MRA Routeplanner has been to develop using the OSM base map, and then load the GPX into my Garmin XT for route execution. Over the past year, that process has worked without issue.
This is actually the first time in almost a year since I've tried the App again. I've been toying with the idea of migrating to CarPlay, so I thought I'd try the App out again first. My impression right now is that MRA w/HERE may not be the right solution for me.
-
In my opinion: The point is on the (HERE) road so if the cursor while driving was on the (HERE) road too, then the point (7) should have been registered. Of course I dont know if this is possible to implement.
I have had a similar but different case : the app registered that i had reached a waypoint which was slightly off the road but the navigation did not so it sent me back (despite the fact that the new target point was the next). The logic that checks wether a waypoint has been hit seems loosly connected to the navigation logic.
-
In my opinion: The point is on the (HERE) road so if the cursor while driving was on the (HERE) road too, then the point (7) should have been registered. Of course I dont know if this is possible to implement.
I have had a similar but different case : the app registered that i had reached a waypoint which was slightly off the road but the navigation did not so it sent me back (despite the fact that the new target point was the next). The logic that checks wether a waypoint has been hit seems loosly connected to the navigation logic.
@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.
-
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.
-
@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.
@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 needBlackView BV7100, Android 12
Navigate "Routes as Tracks" in Offline mode with Offline Maps
No Wifi, no internet, no interruptions, works well -
@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@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....
-
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 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 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 navigatorhow many other apps & navigation systems allow such a large variety of maps & route calculators
-
@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 the 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 will do in the future. Given HERE anomalies,
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login
-
017290
-
8435
-
0459
-
014375
-
17424
-
015462
-
110142
-
0279
