Hi. Do the set extreme min/max zoom values affect the intermediate values? Is only extreme can be set, and intermediate ones are permanently assigned?
I am asking because at a speed of ~60 km/h I would prefer a smaller zoom value, and it seems to me that changes in settings do not affect it.
Speed based auto zoom is combined with visible distance factor, then capped by user min/max options.
There could be minor adjustments if explain in detail how expect it to work and most users agree to that.
I am a fan of setting everything up to my own taste. Therefore, in addition to the min and max zoom settings, I would also like to set the corresponding min and max speeds. So, four parameters instead of two.
For example: I set zoom 17 at speeds below 15 km/h and zoom 14 at speeds above 100 km/h. Intermediate zoom values could be interpolated, e.g. every 0.5 zoom value (or e.g. every 20 km/h if easier to implement). In this way, everyone has adjusted levels based on own preferred speed, zoom and screen size (!). It makes sens?
Are there any navigators that work with all those available options?
Current implementation is not as primitive as described above - with only a simplistic interpolation.
The algorithm includes also visible distance based on screen size or else result would be awkward.
I have no idea because for 20 years on a motorcycle I have only used several Garmins, with auto-zoom turned off. Kurviger is the first I can’t use without auto-zoom on 
OK. Thanks for the explanation - I thought it was less complicated. But I still think the user should be able to influence the whole range of zoom values, not just the extreme.
I am sorry to reheat the thread, but after traveling almost a thousand kilometers with Kuriger, I still think about greater freedom in personalizing the zoom levels automatically selected by the application.
If there were more interest in this, would the solution used in OsmAnd+ be difficult to implement? This could have an impact on faster/slower time to reach subsequent zoom change thresholds, between defined min and max.
I could see if there is available area for enhancements, as auto zoom is already quite complicated.
I hope this won’t complicate much more…
I noticed that the zoom change thresholds are constantly: 40, 60, 80, … kph (until reaching the speed at which the required minimum zoom value is set). Right? Thus, the OsmAnd style solution shown above could impose multipliers to these values - e.g. ×0.75 / ×1.00 / ×1.25.
So:
To long-range (×0.75) → 30, 45, 60, … kphTo mid-range (×1.00) → unchanged 40, 60, 80, … kphTo close-up (×1.25) → 50, 75, 100, … kphSuch a procedure would allow everyone to adjust the zoom changes style to suit their driving style. Believe me, for many oldtimer drivers (to which I myself belong), 80 kph is the end of the scale - that is, they will never reach the target zoom value set in the application 
Speed based auto zoom is a dynamic process. Cannot easily expose speeds, but could scale it.
An auto zoom scale option will be included, so can further adjust speed based auto map scaling.
Hi. Do I understand correctly that we can expect new speed-based zoom options in the near future? It would be nice not to have to use manual zoom-out dozens of times during the trip
Some kind of extra scale option of the speed auto zoom result, so that can adjust it further.
Super. Thanks for your commitment and understanding the needs of the Kurvigers! 
Today I did several dozen kilometers with the 1.14.1 beta version and the new rescaling option seems to work very well, but requires testing…
Many thanks for listening to my pleading plea!
Everyone,
after doing enough testing please share your auto zoom scale preference,
along with your device model and screen orientation (portrait / landscape),
so we can see which scale users prefer based on their device screen size.
unfortunately I am again the nasty user who would not use speed base auto zoom. But only for the reason why I would like to have it exactly the other way round: zoom in more at higher speed (because I only want to see the next 2-3 curves at the biggest width when I am in the pusher mode)… and zoom out at lower speed to get a better overview of the area… this also leads me to a former question if the overview mode can be more detailled, for example by steps of kilometer sections, settable by configuration to for example 5km, 10km, 20km, 50km, 75km, 100km sections. Reason: I mostly plan day trips of more than 300km, up to 500km and when then the overview mode is used, everything is so small that it is not useful any more to have a tour overview where the position follows the GPS position (follow mode). I hope I explain it right, because english is not my native language.
is there any chance to realize such or is it much too complicated?
Also, is it possible to split the overview mode in configurable sections of kilometers like mentionened above?
This feature topic is about speed based auto zoom control.
For new suggestions please create a separate topic for each idea.
Then community can discuss and we can see if it’s needed and if / how it can be implemented.
Regarding the new auto-zoom scaling, however, it’s not as good for me as I initially thought. I am still not able to configure it so that while driving 80-90 km/h I can see the ~3 km route ahead.
The current settings are: Min 13.0 / Max 17.0 / Scale 50%; Samsung Tab Active2 with 8” / 254 dpi / landscape screen.
I’m not sure if I understand the algorithm correctly, but maybe extending the scale from a minimum of 50% to e.g. 20% would help?
Depends also on screen dpi / size, larger screens show more map.
What is your desired zoom? (if zoom via gestures / buttons)
Is the min zoom option set less than that?
I could extend the slider, but need first to collect user preferences about this new feature.
Yesterday I experimented a little bit with the scale factors: 50% 100% 200%
My Impression was that the difference could be more.
Maybe 25%-400%
Maybe 15%-200%
min zoom 13.6
max zoom 16.1
Kurviger Pro 1.14.1
Android 8.0.0 (API 26)
samsung SM-G930F
1080 x 1920 (480 dpi)
I noticed that min zoom was never reached.