gpx imported into MRA adds erroneous turns
-
I often plan routes in BaseCamp and import into MRA so my riding friends can grab them. Lately I've seen some problems with the accuracy in MRA.
The top photo shows the correct routing. The lower photo shows the odd glitch in MRA.
-
@Karen-Sturzenacker maybe stop using kast century basecamp and start planning in MRA, the far most better choice
-
@Karen-Sturzenacker The reason for the route deviation is probably the double solid line that must not be crossed. If you turn on Streetview, you can see it.
Kindly regards
ReinhardZumoXT, Zumo 590, Montana 700i and Mac
-
Just my opinion.... This has nothing to do with the use of Basecamp (which I haven't used for several years as it has the worst user interface known to man) to create the tracks. It has to do with MRA's creating of routes from ANY .gpx file tracks using the HERE map, regardless of where they came from.
Over the past month or more I have documented several times to MRA support via support tickets where MRA using the HERE map creates routes that clearly deviate from the track track shown in the imported .gpx file for some unknown reason.
Switching to the TomTom map or the OpenStreetMap map immediately fixes the issue and the track is followed exactly when the route is calculated. Kurviger also follows the track perfectly when creating the same route from exactly the same .gpx file.
MRA, when using the HERE map, consistently, blatantly ignores the track indicated in the .gpx file when creating the route in my experience. Even my Garmin XT, which is notorious for creating routes that defy any logic follows the .gpx tracks better when creating its routes than MRA does using the HERE maps.
MRA is simply inconsistent when it creates routes using the HERE map from track files and inferior to the competition in this regard. Don't get me wrong. I'm a huge fan of MRA and I think that it's by far the best routing app available, but I've struggled with this issue for a couple of months and to me it's a very clear (and frustrating) issue.
I'll be glad to document these anomalies that I've already documented with support if anyone is interested. So far I have not gotten a reasonable explanation for this behavior.
Yes, I know.... I can easily add additional waypoint/shaping points to force the Here map calculation to follow the track, but why should I have to when using either of the other two maps follows the track perfectly, as does the competition???
Something isn't right.
If I choose the TomTom or OpenStreetMap maps, or if Kurviger calculates the conversion from track to route properly and the HERE map algorithm consistently doesn't then there's clearly a bug or faulty algorithm somewhere, either on MRA's end or the HERE map's end IMO. Until that's recognized the problem won't be fixed.
If I'm wrong I'd love to hear a logical explanation as I haven't gotten one yet.
-
@Steve-Jarrell Creating routes from tracks will never be guaranteed the same. This is also indicated with a warning when doing so.
Navigating a track (without any conversion) in the app should work as expected - meaning the track is followed as imported. Any differences are indicated. There were some issues on recalculation fixed in 4.3.7.
-
@Corjan-Meijerink I understand completely, and I check every route that I create from a track waypoint by waypoint with the track overlaid. I even often add additional waypoints on either side of a potentially confusing intersection or move waypoint away from potential conflicts.
My point is that the HERE map track-to-route calculation is consistently inferior to the other two choices in MRA, inferior to Google maps, inferior to Kurviger, and even inferior to my Gamin XT's track to route calculations. I have submitted several support tickets in the last 5 or 6 weeks clearly documenting this.
I don't know if MRA has any control over why the HERE map's track-to-route calculations are inferior, but if not perhaps this should be taken up with whoever does. Since the HERE map seems to be the preferred choice in MRA, I would like to think that it was equal to, if not better than, the other choices when creating routes from tracks.
It's not.
-
@Steve-Jarrell I get the point you make.
However now we support track navigation, there is no real need to convert them anymore
It’s such a difficult process to convert tracks to routes as it requires placing at some very precise points to approach the real track. Finding those algorithmically is hard. Aligning it across all map providers is merely impossible.
Hence the warning in the website and that’s why we support track navigation
-
@Corjan-Meijerink I do understand your point, however when planning a trip routes have a lot of advantages over just a track or a route-track. Many times I want to start a route with track files created by others as a starting place, convert them to a route and then modify them as I see fit. Hopefully someday the HERE algorithms for creating the routes from tracks will be as good as the other maps and service.
Until then I will just check them closely.
If I do just want to follow a track or route-track it does work brilliantly!
Thanks for your consideration. I do love MRA and this is a small inconvenience compared to all of its advantages.
Steve
-
@Reinhard-32 thank you for your reply. However, in the US, we ARE allowed to cross over a double yellow line when making a left turn as long as there is not signage indicating "no left turn".
The double yellow lines are primarily used to indicate that one car cannot pass to the left of another that is traveling in the same direction.
-
@Karen-Sturzenacker
I think it is odd also.
If there was a routepoint on the crossing where you have the strange loop. Then you could see some logic of the loop.But there is no waypoint on that crossing. From what i know. Routes are calculate from point to point. So why the strange loop.
If route is created by following the track as close a possible. Then there is logic also. But what is function of waypoints in this situation
