MRA Community Forum

@LennyO OK, so do you still believe your previous statement that "HERE somehow screwed up and we are at the mercy"? If the MRA version of HERE, in many cases, has a different routing algorithm than OSM/TomTom that simply favors more major roads, where is the screw up? I'm asking from the position of understand/learning.

I have a route in my library titled Bridge motorcycles, the distance is 117 miles with an estimated time of 2 hours 30 minutes. When I open the route for navigation I am shown the exact same distance and time, after I tap navigate the time is 2 minutes longer. I expect this as I am navigating offline. If I now switch to online you will see by the time in the blue box that an additional 23 minutes have been added to account for traffic delays. [image: 1784903522563-46d15f23-76a2-48b2-b3d4-e31eb33f9800-image.jpeg] ........ [image: 1784903624716-86b26bc0-5600-4465-95cf-f826f0a66fc6-image.jpeg] ........ [image: 1784903723917-7eb92b34-0b36-4c38-b9e4-10e53425ae18-image.jpeg] ...... [image: 1784904197954-2b358011-95fd-4338-8fd0-7f175fadecc2-image.jpeg]

That´s why pictures help.

@Lenny-O What a nice and clear story! I have my phone in an SP-Connect mount. This ensures it gets sufficient cooling from the airflow. (i.e., up to about 35 degrees; when it started heading towards 40 degrees, it really struggled, but I don't blame it for that) I'm curious to hear the continuation of the story!

@Hans-Rutten the short answer is if you have an MRA Gold subscription to use the "Compare" tool [image: 1784883413629-9255862b-253c-4daa-960c-969d662d1a96-image.jpeg] In the above picture the algorithm being used to calculate the route is the Here algorithm & it can be "Compare" to the OpenStreetMap or TomTom route calculators the long answer .............. is that the routing algorithms that calculate the route for Here & TomTom are different, as is the underlying map data that the algorithms use to calculate the path of the route The larger the distance between any 2 points you place, the larger the number of possible different paths the algorithms can choose from & the greater the number of differences in the underlying maps (the average speeds on the roads) that the algorithms can also choose from In the picture below the route is a simple 2 points placed 66 miles apart & each of the different algorithms, Here (black line), OpenStreetMap (blue line) & TomTom (red line) calculate routes completely differently because of the difference in the algorithms & underlying data in their maps [image: 1784883595858-331a503d-393f-47ce-8de8-882a64982c22-image.jpeg] The same effect can happen when 2 points are placed closer together, 5 miles or even 1 mile apart IF there are different possible paths for the algorithms to choose from between 2 points it is possible for the paths to have different underlying data & the algorithms can calculate different routes The way to solve this is to "constrain" the route so that there are not 2 different paths for the algorithms to choose from This is done by adding extra points, normally shaping points, to force the route onto the preferred path of your choice. In the example I am using with 66 miles between points, adding an extra point constrains both OpenStreetMap & the TomTom algorithms to choosing a route via the west of London [image: 1784885466408-948a045f-3c04-4eb0-aca5-0936829f4017-image.jpeg] At the beginning & end of the route the OpenStreetMap route calculation is still different to that of the Here & TomTom routes because there are still multiple different optional paths for the algorithms to use even at this shorter distance Additional points would need to be added to more completely constrain the algorithms onto the same roads & make all 3 algorithms use the same route The above example with 66 miles between points, in an area like the south of the UK where there is a large network of roads, is extreme (or lazy) & is bound to cause problems with different routes being calculated, it is only an example to illustrate the issue. Normally you would place points a lot closer together depending on the density of the road network & the number of possible different path options between points If you are sharing your routes with friends that use navigation systems other than MRA, it is a good idea to make sure your routes are tightly constrained i.e. you add a lot of additional points to prevent the algorithms on the other navigation systems calculating a route via a different alternative path

@Stevedo-6-0 agreed. The old adage of crap input, crap output is valid. It wouldn't necessarily need to be the OSM data. Google and HERE both show speed limits of a road (which itself isn't 100% accurate) when navigating so the data of speed limits is there, I guess it's just a case of whether a) that data is accessible b) whether the data is prohibitively expensive c) can it be coded into MRA simply Any of those 3 may be impossible to resolve in a cost effective and proportionate way.

@De-Ploey-Georges zoals @nick-carthew al zei het Rode stuk is het noorden en dus niet de richting waarin je aan het rijden bent. Als je dynamische camera mode aan hebt staan zie je ook dat de pijl in die camera aanduiding ook altijd richting noorden wijst

Yes, as a monopoly, you can get away with this! Just like you, every beta tester with an Android phone is now biting their nails, waiting for the long-awaited message!

AA and ACP are an extra layer of complexity but they are certainly not the cause of most problems.

Sono impazzito per lo stesso motivo!

@Mzokk yep, also a longterm garmin user but i recently got myself an XT2 and the sh.t began, i have had (almost) no problems with the XT1 but now i am thinking of going another path as carpuride or similar to use MRA...

@Aggelos-Minoudis have you set aan avoidance of hiways active

@white.mouse Het is niet zo'n big issue. Het viel me op en ben es gaan neuzen. Maar zo mis je wel een mooi fotolocatie Heb het ondertussen ook al gerapporteerd.

@Adrian-Avram, It does. If the upload did not work, you will see a small up-arrow in the profile icon, until it resolves itself. One problem though, which I experienced myself last week, is the addition of extra pictures. The ones you did not take with the built in camera app, but decide to pick from your own gallery. That seems to only work if you do that just before uploading. All pictures I attached during the day did not get uploaded on multiple occasions. Besides that, there is no means of adding those pictures after you uploaded the tracklog. Hopefully that will be added some day too.

Op de Carpuride Android Auto afsluiten en daarna weer opstarten heeft bij mij in het verleden altijd geholpen.

Ah! Thats new to me, thanks for the explanation!

Because some apps can run in the background and are not really active on that moment.