Concerning strict navigation I am over the moon. Unfortunately not about the weather, because that prevents me from trying it out right away. It works well when simulating. Even the manual skipping works like expected. I am confident that this will also work well in real operation. The next complex round trip is mine.
Thanks for your explanation. If I’m using “strict navigation” and am forced to leave my route, will I then be navigated to the next omitted waypoint regardless what type it is (regular or shaping wapoint)? Or will I be navigated to omitted regular waypoints only? My question is related to my former posts concerning this function (like here or here). Or from other users (like here).
Shouldn’t it have rerouted to nearest point on route at start of navigation?
Ich bin am Anfang mit “Strikte Navigation” gefahren, auch nach dem “Neustart”. Erst als ich ca. 2 km am WP1 vorbei war und Kurviger immer noch zu WP1 wollte, was in diesem Modus ja richtig ist, habe ich wieder auf “Folgender Wegpunkt” umgeschaltet.Worauf hin Kurviger zum WP2 sprang.
I drove with “Strict Navigation” in the beginning, even after the “Restart”. Only when I had passed SS1 for about 2 km and Kurviger still wanted to go to SS1, which is correct in this mode, I switched back to “Following Waypoint”, whereupon Kurviger jumped to SS2.
Does this description explains that better?
Navigate along the route without shortcuts, i.e. follow the route strictly from one via point to another. When go off route, the rerouting tries to resume to the last omitted via point.
Essentially like discussed and agreed here, the shaping points are considered after the first via point that participates in rerouting.
Do we need all this rerouting options
I think at the end two options should remain:
- a flexible one, which allows automatic skipping of waypoints that are “behind” you.
- a strict one, which doesn’t omit waypoints.
See my comment here
(App: Rerouting options)
(we can also discuss that in the relevant topic)
I am available for changes if there is enough feedback - not many have participated so far.
Are there any DIS-advantages?
If not - me I always prefer more options compared to less.
Ein Mehr an Auswahl kann aber Nutzer abschrecken, wenn es zu viel wird. Zumal ich nicht denke das sich Alle die FAQ oder das Handbuch durchlesen. Ich denke die Meisten werden sich, so wie ich, die App installieren und losfahren wollen. Ohne sich groß Gedanken machen zu müssen welche Einstellungen Jetzt die richtigen wären. Deswegen finde ich Weniger aber Bewährtes persönlich besser.
However, more choice can deter users when it becomes too much. Especially since I don’t think that everybody reads the FAQ or the manual. I think most of them will want to install the app and get started, just like me. Without having to think about which settings are the right ones now. That’s why I personally find less but proven things better.
This we had discussed often in this forum as well.
WHO’s the one to decide, which options are more useful and which are less useful?
Only in very few cases can an agreement be reached.
And then any restriction of options is a loss for at least one part of the target group.
Therefore, it is better to leave the options as they are, if they have already been implemented by the developers, i.e. do not require new efforts.
Ich gebe Ihnen dahingehend Recht das die Funktionen momentan eingebaut sind. Was wir aber nicht vergessen dürfen, dies ist eine Beta-Version welche, meine Vermutung, nicht durch die breite Masse genutzt wird. Betas sind zum testen da, wenn festgestellt wird Ok das passt oder passt nicht, werden entsprechende Änderungen vorgenommen oder alles gelassen wie es ist. Im Forum habe ich auch schon von @devemux86 gelesen, das nicht alles unumstößlich ist. Vielleicht hilft manchmal eine Umfrage weiter wer welche Funktion nutzt?
I agree that the functions are currently installed. But what we must not forget, this is a beta version which, my guess, is not used by the masses. Betas are there for testing, if it is found Ok that fits or does not fit, appropriate changes are made or everything is left as it is. In the forum I also read about @devemux86, that not everything is irrefutable. Maybe sometimes a poll helps who is using which function?
I agree … and I’d like to keep the “Settings | Routing | Waypoints in instructions” for same reasons.
Yes, absolutely. Now it’s clear that rerouting only considers the next regular (“via”) waypoint without loosing all the shaping waypoints following after it. Sounds quite perfect for me (will be tested as soon as possible). Thank you.
I would agree with that. I think “nearest route point” and “nearest waypoint” could be removed. I don’t think those options are very useful. But depending on the route and your current position they could have quite undesirable effects.
Hmmm, usually I also prefer to have different options to configure a tool for my personal preferences. But too many rerouting options may confuse unexperienced user (or those who didn’t follow all the discussions in this forum ).
Yes, reasonable point.
Hmmm, yes - maybe you’re right. I’m really very torn …
And what then about the minorities? This would only make sense, if any option has NO proponents at all.
Not to be expected.
But perhaps better outsource this fundamental question, how to deal with multiple “necessary or unnecessary” options and the “overloading” with possible options, in another thread?
(That’s up to @devemux86.)
Polls hold only a small part in the non-deterministic development algorithm.
As a developer more important are stability, performance and maintenance.
By the way please let’s continue discussion for rerouting options in its topic:
Coming again in next (beta) version.
By clustering the markers, we can put a large number of markers on the map without making the map hard to read and hurting app performance.
Available in “Settings | Map | Maximum zoom level of marker groups” for bookmarks, GPX, etc.
- Various improvements
sounds good, not yet available on my device, probably takes a while… but I have another question:
since 1.13.2 it should work to rename Waypoints and switch between regular and shaping. This is not working for me. Nothing happens when I long-press on a waypoint (still 1.13.5).
When long press on (yellow) via points or (white) shaping points, their dialog appears with different actions per type. The via points offer the “Edit” action to rename them.
Long press menu on waypoints works if enable the “Settings | Map | Crosshair placement”.
Ah ok, yes, then it works. Thanks.